perm filename BIG5.MSG[COM,LSP]11 blob
sn#876446 filedate 1989-08-28 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂03-Apr-89 0908 Quinquevirate-mailer Starting Up
To: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Folks, as usual I've started up a mailing list for this
little subgroup. Luckily there are 5 of us so I recycled
this one:
quinquevirate@sail.stanford.edu
with the archive file:
big5.msg[com,lsp]
Some might not like the imperial tone of it all, but it's simply
too much hassle to add another mailing list to the ones SAIL knows
about already.
Here is what ISO decided, which has implications for us:
1. A draft of ANSI Common Lisp shall be delivered to the member
delegations so as to arrive by July 31.
2. The draft shall be accompanied by a document that outlines how
X3J13 evaluates that draft. This is a rationale statement and should
discuss those criteria we use for judging changes made to Common Lisp
and for judging the quality of the draft itself.
3. Optionally, we can supply a document that outlines our constructive
criticism of an existing Lisp and its specification as an international
standard.
In short, the German proposal was accepted and we are now in the process
of selecting drafts/languages to possibly standardize. There is currently
some question as to how many standards will be accepted, and I have
announced to WG16 that the US will decide whether to submit both Common
Lisp and Scheme or only Common Lisp based on our guess as to which of the
paths is most likely to result in an ISO Common Lisp.
During discussions with Chailloux, he remarked that all he really wanted
was a core language that was a subset of both Common Lisp and LeLisp.
This was news to me, and during further discussion it became clear that he
was technically confused about what a core language was and so explained
the funny set of changes he proposed to Common Lisp in the so-called AFNOR
plan. I think defining a core of Common Lisp according to his intentions
is relatively simple, since it is a core language rather than an
independently useful dialect.
I believe our charter includes the authority to make virtually any
editorial decision and some minor technical decisions. The latter should
be almost entirely of the form of deriving conclusions from decisions made
by X3J13, but I can imagine making decisions about things that were
overlooked. The largest decision I can imagine us making is a compromise
on the adjust-array question if that decision is consistent with existing
practice and all that has been decided by X3J13 already. (Actually, I
don't expect we will be able to make such a decision, but it is an
example. The key point is that I think we understood what was meant in
Kauai about the resolution that passed, but that resolution was
technically flawed. We could clean up that resolution.)
I plan to do some re-writing if that is acceptable. Right now I am willing
to rewrite the history section and the sections on conditions. I am also
willing to edit those other sections where my reviews outline a lot of
problems. I think we should do this by a checkout mechanism where KC is
the locking device. That is, we should ask her to check out a file or
group of files, and when we are done, should be have the authority to
compare our version with the older one and to merge them as she sees fit.
-rpg-
∂06-Apr-89 1033 Quinquevirate-mailer Notes from 4/3 meeting
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Apr 89 10:33:03 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05156; Thu, 6 Apr 89 10:33:59 PDT
Message-Id: <8904061733.AA05156@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA05156; Thu, 6 Apr 89 10:33:59 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Apr 89 12:23
To: quinquevirate@sail.stanford.edu
Subject: Notes from 4/3 meeting
Drafting Committee meeting notes, 4/3/89, 10:30-12:30, Thinking Machines
Attendees: Masinter, Moon, GLS, Chapman
Goals:
1. Complete review/rewrite by this committee by 6/26 meeting.
2. Mail a ready-for-review draft to ISO delegations by 7/14/89
(deliver in person to French delegation to enjoy quatorze juillet??).
3. Make parts of the standard available to X3J13 as they become
reviewed/rewritten. Perhaps these will be letter ballots, or just
info copies.
4. Make complete standard available to X3J13 for review after 6/26
meeting. Accept and respond to comments until the November meeting.
5. Review this plan by 4/14/89.
Other notes:
About the standard:
1. Suggestion to can the Side Effects section. No significant disagreement.
2. Suggestion to move from section 2.2 (types) anything that has to do
with external representation to appropriate sections (3.1, 3.2, or
description of write function). No disagreement.
3. Suggestion to move processing rules from section 2.2 to a separate section.
Seems reasonable to move them to section 6.1 (Introduction to Catalog
of Defined Names) under a special subsection heading ("Rules") and
special subsubsection headings, one for each type.
4. After all the Jan and March issues are included, a guess will be made
as to which issues will pass in June, and those issues will be included.
Anyone wishing to make a stab at that list now is more than welcome. Otherwise
that list will be coming to you for review in about 3 weeks.
5. See the editorial committee report for other changes that have been
or will be made to the standard.
Administrative:
1. New draft of the standard was moved to hudson.dec.com today. It is the latest
version but with only editorial changes since March meeting (only editorial
issues and proposals included).
2. The subject of a mailing list was brought up and rejected, but RPG
had already set one up. Would you prefer I list your names, or is the
mailing list okay?
3. I will send you copies of what you need as they are finished and as
follows:
Who How What
------------------------------------------------------------------------
RPG Mail Source files and a build file.
Masinter Mail+FTP List of source files and build files.
Moon Mail+FTP+USMail Source files, hardcopy
GLS USMail Hardcopy
4. I will send the sections that are ready now while we are reviewing this
plan. If there are changes, I will remail to the proper person.
5. The original plan for this group had people working together
on certain sections. I have not listed pairings here and will wait
for you to ask me to work out those details. If you intend to change
a section that someone else has completed, please copy the person
whose section you're changing and me on the changes.
6. I won't be making changes to source files while you have them.
Chapter 1. Introduction
CONTENTS
1.1 Scope, Purpose, and Application RPG 6/14/89
1.2 Organization of the Document Done
1.3 Referenced Publications Done
1.4 Definitions Done
1.5 Compliance KC 5/1/89
1.6 Language Extensions KC 5/1/89
Chapter 2. Objects and Types 4/1/89 4/14/89
CONTENTS
2.1 Introduction Done
2.2 Types Moon 5/1/89
2.3 Classes Done
2.4 Slots Done
2.5 Objects Done
Chapter 3. Object Syntax
CONTENTS
3.1 Character Reader RPG 5/1/89
3.2 Object Syntax RPG 5/1/89
Chapter 4. Evaluation and Compilation
CONTENTS
4.1 Evaluation Model Moon 5/14/89
4.2 Compilation RPG 6/14/89
Chapter 5. Other Topics
CONTENTS
5.1 Errors RPG 5/14/89
5.2 Input/Output Masinter 5/1/89
5.3 Interface with the Programming Environment Masinter 5/1/89
5.4 Generalized Reference Masinter 5/1/89
Chapters 6 and 7. Catalog of Defined Names
CONTENTS
6.1 Introduction RPG 5/1/89
The following list contains the names of groups of functions as they
appear in CLtL, CLOS, and the Condition System documents. For example,
Masinter is to review/rewrite the functions in Chapter 15 (Lists) of
CLtL by 5/1/89.
CLOS RPG 5/1/89
PREDICATES Masinter 5/1/89
STRINGS Masinter 5/1/89
SEQUENCES Masinter 5/1/89
LISTS Masinter 5/1/89
NUMBERS Masinter 5/1/89
STRUCTURES GLS 5/14/89
SYMBOLS GLS 5/14/89
HASH-TABLES GLS 5/14/89
ARRAYS GLS 5/14/89
TYPES GLS 5/14/89
DECLARATIONS GLS 5/14/89
IO Masinter 6/14/89
STREAMS Masinter 6/14/89
FILE Masinter 6/14/89
CONTROL Masinter 6/14/89
PROGRAM Masinter 6/14/89
MISC Masinter 6/14/89
ERRORS RPG 6/14/89
MACROS Moon 6/14/89
PACKAGES Moon 6/14/89
CHARACTERS Moon 6/14/89
EVALUATOR Moon 6/14/89
Glossary RPG 5/1/89
RPG: 1.1, 3.1, 3.2, 4.2, 6.1, 5.1, CLOS, Errors, Glossary
Masinter: 5.2, 5.3, 5.4,
PREDICATES, STRINGS, SEQUENCES, LISTS, NUMBERS, IO, STREAMS,
FILE SYSTEM INTERFACE, CONTROL STRUCTURE, PROGRAM STRUCTURE,
MISCELLANEOUS FEATURES
Moon: 2.2, 4.1, MACROS, PACKAGES, CHARACTERS, EVALUATOR
GLS: STRUCTURES, SYMBOLS, HASH-TABLES, ARRAYS, TYPES, DECLARATIONS
Sections that are ready now: 1.1, 4.1, 5.1, 5.2, 5.3, 5.4, CLOS.
It is not felt that these sections will change much as a result
of issues that haven't been included.
Note that 5.2-5.4 "passed" at the meeting, but Larry and others still
feel there is work to be done on them.
Other sections will be ready when the issues and proposals passed in
Jan and March have been completely included.
Thanks in advance for your time.
kc
∂07-Apr-89 0752 Quinquevirate-mailer ftp files
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Apr 89 07:51:05 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA07960; Fri, 7 Apr 89 07:51:30 PDT
Message-Id: <8904071451.AA07960@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA07960; Fri, 7 Apr 89 07:51:30 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 7 Apr 89 10:43
To: quinquevirate@sail.stanford.edu
Subject: ftp files
Please let me know before you take a file from hudson.dec.com for
the purpose of changing it. I will assume that I am free to make
changes in files that I have not explicitly mailed to you (or the
pointers to you) or that you have not told me you were changing.
kc
∂07-Apr-89 0759 Quinquevirate-mailer checked out status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Apr 89 07:59:31 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA08905; Fri, 7 Apr 89 07:59:48 PDT
Message-Id: <8904071459.AA08905@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA08905; Fri, 7 Apr 89 07:59:48 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 7 Apr 89 10:57
To: quinquevirate@sail.stanford.edu
Subject: checked out status
Section Who has Date out
1.1 RPG 4/7/89
1.2
1.3
1.4
1.5
1.6
2.1
2.2
3.1
3.2
4.1 Moon 4/7/89
4.2
5.1 RPG 4/7/89
5.2
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
Glossary
CLOS
PREDICATES
STRINGS
SEQUENCES
LISTS
NUMBERS
STRUCTURES
SYMBOLS
HASHTABLES
ARRAYS
TYPES
DECLARATIONS
IO
STREAMS
FILE
CONTROL
PROGRAM
MISC
ERRORS
MACROS
PACKAGES
CHARACTERS
EVALUATOR
∂11-Apr-89 0813 Quinquevirate-mailer checked-out sections
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 11 Apr 89 08:13:27 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA00365; Tue, 11 Apr 89 08:13:59 PDT
Message-Id: <8904111513.AA00365@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA00365; Tue, 11 Apr 89 08:13:59 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 11 Apr 89 11:07
To: quinquevirate@sail.stanford.edu
Subject: checked-out sections
Section Who has Date out
1.1 RPG 4/7/89
1.2
1.3
1.4
1.5
1.6
2.1
2.2 Moon 4/11/89
3.1 Masinter 4/11/89
3.2 Masinter 4/11/89
4.1 Moon 4/7/89
4.2
5.1 RPG 4/7/89
5.2
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1
Glossary
CLOS
PREDICATES
STRINGS
SEQUENCES
LISTS
NUMBERS
STRUCTURES
SYMBOLS
HASHTABLES
ARRAYS
TYPES
DECLARATIONS
IO
STREAMS
FILE
CONTROL
PROGRAM
MISC
ERRORS
MACROS
PACKAGES
CHARACTERS
EVALUATOR
∂11-Apr-89 0852 Quinquevirate-mailer
To: quinquevirate@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.SYMBOLICS.COM
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Glossary
KMP writes:
`` - I feel funny about the use of the word ``contains'' in ``generic
function.'' ''
The reason to use it is that some people have the idea that a
generic function is really just a name and that there are
a set of methods that are associated with that name. A test of this
misconception is to see how they react when you say you want to
save the old definition of a generic function G by grabbing #'G,
dork around with a new definition of G, and then restore the old one.
That is, the word ``contain'' is intended to make you think that when
you pick up a generic function object, the methods ``come along too.''
The word ``contain'' probably implies slightly too much about implementation,
but a generic function acts as if the methods and the method combination were
part of it.
KMP, would you feel that some phrasing that said that a generic function
was simply a function and could be used exactly the same way would preclude
people from thinking generic functions were amorphous?
Also, note that the current glossary definition is pretty much excerpted from
88-002R.
-rpg-
∂11-Apr-89 0903 Quinquevirate-mailer Progress
To: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I have the history section checked out. What I'm trying to do with it
is to outline briefly what the various roots of CL contributed, and
to give an idea of the family tree of Lisp. I hope that I use
about the same space. I'm 1/2 done with this rewrite.
As I mentioned to KC earlier, my schedule until April 26 is pretty
bad (180 OOPSLA papers to read). After that, I plan to devote almost
all of my time to the draft. I think Steele's schedule has a similar
shape.
-rpg-
∂11-Apr-89 0911 Quinquevirate-mailer glossary description of `generic function'
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89 09:11:02 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 575190; 11 Apr 89 12:11:01 EDT
Date: Tue, 11 Apr 89 12:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: glossary description of `generic function'
To: RPG@SAIL.Stanford.EDU
cc: quinquevirate@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <UMWcZ@SAIL.Stanford.EDU>
Message-ID: <890411121004.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
I see your point, and I agree with your concern. Part of my problem,
perhaps, was the harsh and unmotivated transition from a generic
function as a function to a generic function as a container. How
about something like...
generic function - a <function> whose behavior depends on the <classes>
or <identities> of the arguments supplied to it. Unlike an ordinary
<function>, a <generic function> can also be viewed as an <object> with
state that can be examined and modified without actually invoking the
functional component. This state includes, among other things, a set
of <methods>, a <lambda list>, and a method combination type.
∂11-Apr-89 0927 Quinquevirate-mailer Glossary
To: quinquevirate@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.SYMBOLICS.COM
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Hm, how about this:
generic function - a <function> whose behavior depends on the <classes>
or <identities> of the arguments supplied to it. Unlike an ordinary
<function>, a <generic function> is also an <object> whose parts include,
among other things, a set of <methods>, a <lambda list>, and a method
combination type.
∂11-Apr-89 0930 Quinquevirate-mailer Glossary
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89 09:30:26 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 575205; Tue 11-Apr-89 12:30:26 EDT
Date: Tue, 11 Apr 89 12:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Glossary
To: RPG@SAIL.Stanford.EDU
cc: quinquevirate@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <UMXDp@SAIL.Stanford.EDU>
Message-ID: <890411122944.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 11 Apr 89 0927 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Hm, how about this:
generic function - a <function> whose behavior depends on the <classes>
or <identities> of the arguments supplied to it. Unlike an ordinary
<function>, a <generic function> is also an <object> whose parts include,
among other things, a set of <methods>, a <lambda list>, and a method
combination type.
Fine.
∂12-Apr-89 1449 Quinquevirate-mailer checked out (4/12)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Apr 89 14:49:21 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA22640; Wed, 12 Apr 89 14:49:51 PDT
Message-Id: <8904122149.AA22640@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA22640; Wed, 12 Apr 89 14:49:51 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 12 Apr 89 17:46
To: quinquevirate@sail.stanford.edu
Subject: checked out (4/12)
Section Who has Date out
1.1 RPG 4/7/89
1.2
1.3
1.4
1.5
1.6
2.1
2.2 Moon 4/11/89
3.1 Masinter 4/11/89
3.2 Masinter 4/11/89
4.1 Moon 4/7/89
4.2
5.1 RPG 4/7/89
5.2
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1 RPG 4/12/89
Glossary
CLOS
PREDICATES
STRINGS
SEQUENCES
LISTS
NUMBERS
STRUCTURES
SYMBOLS
HASHTABLES
ARRAYS
TYPES
DECLARATIONS
IO
STREAMS
FILE
CONTROL
PROGRAM
MISC
ERRORS
MACROS
PACKAGES
CHARACTERS
EVALUATOR
!
From: DECWRL::AITG::CHAPMAN "11-Apr-89 1107 GMT" 11-APR-1989 11:18:16.25
To: quinquevirate@sail.stanford.edu
CC:
Subj: checked-out sections
Section Who has Date out
1.1 RPG 4/7/89
1.2
1.3
1.4
1.5
1.6
2.1
2.2 Moon 4/11/89
3.1 Masinter 4/11/89
3.2 Masinter 4/11/89
4.1 Moon 4/7/89
4.2
5.1 RPG 4/7/89
5.2
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1
Glossary
CLOS
PREDICATES
STRINGS
SEQUENCES
LISTS
NUMBERS
STRUCTURES
SYMBOLS
HASHTABLES
ARRAYS
TYPES
DECLARATIONS
IO
STREAMS
FILE
CONTROL
PROGRAM
MISC
ERRORS
MACROS
PACKAGES
CHARACTERS
EVALUATOR
∂13-Apr-89 0226 Quinquevirate-mailer I'd like to send this to X3J13
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Apr 89 02:26:38 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA29997; Thu, 13 Apr 89 02:27:20 PDT
Message-Id: <8904130927.AA29997@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA29997; Thu, 13 Apr 89 02:27:20 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 13 Apr 89 05:24
To: quinquevirate@sail.stanford.edu
Subject: I'd like to send this to X3J13
Since a letter ballot date is approaching, I'd like to send the following
to X3J13 to clarify what has happened with those dates. Do you approve
of sending the following?
kc
The formation of the drafting committee causes scheduled voting dates
on parts of the standard to change. Therefore, if you are planning to
review the document on the schedule set up by the issue CUT-OFF-DATES,
please revise your plan taking the following into account.
From now on the drafting committee will review or rewrite
as necessary according to the following schedule:
Chapter 1. Introduction
CONTENTS
1.1 Scope, Purpose, and Application 6/14/89
1.2 Organization of the Document Done
1.3 Referenced Publications Done
1.4 Definitions Done
1.5 Compliance 5/1/89
1.6 Language Extensions 5/1/89
Chapter 2. Objects and Types
CONTENTS
2.1 Introduction Done
2.2 Types 5/1/89
2.3 Classes Done
2.4 Slots Done
2.5 Objects Done
Chapter 3. Object Syntax
CONTENTS
3.1 Character Reader 5/1/89
3.2 Object Syntax 5/1/89
Chapter 4. Evaluation and Compilation
CONTENTS
4.1 Evaluation Model 5/14/89
4.2 Compilation 6/14/89
Chapter 5. Other Topics
CONTENTS
5.1 Errors 5/14/89
5.2 Input/Output 5/1/89
5.3 Interface with the Programming Environment 5/1/89
5.4 Generalized Reference 5/1/89
Chapters 6 and 7. Catalog of Defined Names
CONTENTS
6.1 Introduction 5/1/89
The following list contains the names of groups of functions as they
appear in CLtL, CLOS, and the Condition System documents. For example,
the functions in Chapter 15 (Lists) of CLtL are to be reviewed and/or
rewritten by 5/1/89.
CLOS 5/1/89
PREDICATES 5/1/89
STRINGS 5/1/89
SEQUENCES 5/1/89
LISTS 5/1/89
NUMBERS 5/1/89
STRUCTURES 5/14/89
SYMBOLS 5/14/89
HASH-TABLES 5/14/89
ARRAYS 5/14/89
TYPES 5/14/89
DECLARATIONS 5/14/89
IO 6/14/89
STREAMS 6/14/89
FILE 6/14/89
CONTROL 6/14/89
PROGRAM 6/14/89
MISC 6/14/89
ERRORS 6/14/89
MACROS 6/14/89
PACKAGES 6/14/89
CHARACTERS 6/14/89
EVALUATOR 6/14/89
Glossary 5/1/89
These dates are goals, not fixed deadlines. However, if you would
like to comment on a section before the reviewer/rewriter works on
it, you should get your comments to me before the date listed for
the section.
When a section is ready for ballot it will be mailed for vote.
The goal is to complete all sections by the June meeting. Coming to closure
on all the sections by the June meeting is not a goal; having all the sections
ready for review by X3J13 between June and September IS a goal.
So if you only have time for one review, you should plan to review after
the drafting committee has completed its work, i.e. around mid- to late-July.
As usual, if you need hardcopies, please don't hesitate to ask. The files
on hudson.dec.com are updated once per week, usually on Tuesday night or
Wednesday morning. If you have trouble accessing them, please let me know
ASAP. If you forgot how to access them, please let me know. Please note that
ALL reviews and comments are APPRECIATED. In most cases, and always when the
comments are on a recently-published version or are extensive, you will receive
replies to your comments.
Thanks again for your help.
the drafting committee
∂13-Apr-89 1037 Quinquevirate-mailer I'd like to send this to X3J13
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Apr 89 10:37:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 576737; Thu 13-Apr-89 13:36:22 EDT
Date: Thu, 13 Apr 89 13:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: I'd like to send this to X3J13
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8904130927.AA29997@decwrl.dec.com>
Message-ID: <19890413173617.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 13 Apr 89 05:24
From: chapman%aitg.DEC@decwrl.dec.com
Since a letter ballot date is approaching, I'd like to send the following
to X3J13 to clarify what has happened with those dates. Do you approve
of sending the following?
It's fine by me. I'm not real good on dates and schedules, so I can't
claim to have carefully checked that the schedule is doable.
The formation of the drafting committee causes scheduled voting dates
on parts of the standard to change. Therefore,....
∂14-Apr-89 0511 Quinquevirate-mailer checked-out (4/13)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Apr 89 05:11:28 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05792; Fri, 14 Apr 89 05:12:12 PDT
Message-Id: <8904141212.AA05792@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA05792; Fri, 14 Apr 89 05:12:12 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 14 Apr 89 08:07
To: quinquevirate@sail.stanford.edu
Subject: checked-out (4/13)
Section Who has Date out
1.1 RPG 4/7/89
1.2
1.3
1.4
1.5
1.6
2.1
2.2 Moon 4/11/89
3.1 Masinter
3.2 Masinter
4.1 Moon 4/7/89
4.2
5.1 RPG 4/7/89
5.2
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1 RPG 4/12/89
Glossary
CLOS
PREDICATES
STRINGS
SEQUENCES
LISTS
NUMBERS
STRUCTURES
SYMBOLS
HASHTABLES
ARRAYS
TYPES
DECLARATIONS
IO
STREAMS
FILE
CONTROL
PROGRAM
MISC
ERRORS
MACROS
PACKAGES
CHARACTERS
EVALUATOR
∂16-Apr-89 2229 Quinquevirate-mailer History Section (1.1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Apr 89 22:29:46 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA08169g; Sun, 16 Apr 89 22:29:50 PDT
Received: by challenger id AA00492g; Sun, 16 Apr 89 22:29:39 PDT
Date: Sun, 16 Apr 89 22:29:39 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904170529.AA00492@challenger>
To: quinquevirate@sail.stanford.edu
Subject: History Section (1.1)
Here is my current rewrite of the history section (1.1). It is a
little more, but slightly more complete while being quite terse (what
it lacks in verbosity it makes up for in terseness). This version is
the result of comments by Masinter and Bobrow, so some of it is
probably accurate. Jonl says he cannot review it for a few months, so
I'll leave it to Steele and Moon to review the Maclisp and Zetalisp
stuff.
%%Scope, Purpose, and History
\beginsubSection{Scope and Purpose}
The specification set forth in this document is designed to promote
the portability of @clisp\ programs among a variety of data-processing
systems. It is a language specification aimed at an audience of
implementors and knowledgeable programmers: It is neither a tutorial nor
an implementation guide.
\endsubSection%{Scope and Purpose}
\beginsubSection{History}
Lisp is a family of languages with a long history. Early key ideas in
Lisp were developed by John McCarthy during the 1956 Dartmouth Summer
Research Project on Artificial Intelligence. McCarthy's motivation
was to develop an algebraic list processing language for artificial
intelligence work.
In 1957, on McCarthy's advice, Herbert Gelernter and Carl Gerberich
implemented a list processing language within FORTRAN, called
FLPL---FORTRAN List Processing Language. This was a set of subroutines
that were added to FORTRAN on the IBM~704 computer. Under the
direction of McCarthy, the first real Lisp---Lisp~1---was implemented
for the IBM~704 computer in 1958. Lisp~1.5 was an extension of
Lisp~1. It was implemented on the IBM~7090 computer at MIT. A later
version of Lisp~1.5 on the PDP-6 was the ancestor of MacLisp.
MacLisp improved on the Lisp~1.5 notion of special variables and error
handling. MacLisp also introduced into Lisp functions that could take
a variable number of arguments, macros, arrays, non-local dynamic
exits, fast arithmetic, the first good Lisp compiler, and an emphasis
on execution speed.
In 1963 L. Peter Deutsch, then a high school student, implemented
Basic PDP-1 Lisp, a Lisp similar to Lisp~1.5, at MIT. At Bolt,
Beranek, \& Newman, BBN Lisp was implemented on the PDP-10 by Daniel
Bobrow, D. L. Murphy, and Alice Hartley. In 1972, the maintenance of
BBN~Lisp---its name changed to InterLisp---was shared by BBN and Xerox
Palo Alto Research Center.
InterLisp introduced many ideas into Lisp programming environments,
style, and methodology. One of them was an iteration construct
implemented by Warren Teitelman which inspired the LOOP construct used
both on the Lisp Machines and in MacLisp, and now in @clisp.
Although the first implementations of Lisp were on the IBM~704 and the
IBM~7090, later work focussed on the Digital Equipment Corporation
PDP-10 computer, which was the mainstay of Lisp and artificial
intelligence work at MIT, Stanford, BBN, and CMU from the mid-1960's
through much of the 1970's.
The PDP-10 computer and its predecessor the PDP-6 computer were, by
design, especially well-suited to Lisp because they had 36-bit words
and 18-bit addresses. This architecture allowed a CONS cell to be
stored in one word; single instructions extracted the CAR and CDR
parts. The PDP-6 and PDP-10 had fast, powerful stack instructions
that enabled fast function calling.
But the limitations of the PDP-10 were evident by 1973: it supported a
small number of researchers using Lisp, and the small, 18-bit address
space ($2↑{18}$ $=$ 262,144 words) limited the size of a single
program.
One response to the address space problem was the Lisp machine, a
special-purpose computer designed to run Lisp programs. The other
response was to use computers with address spaces larger than 18~bits,
such as the Digital Equipment Corporation Vax and the S-1~Mark~IIA.
The Lisp machine concept was developed in the late 1960's. In the
early 1970's, Deutsch, working with Bobrow, implemented a Lisp on the
Alto, a single-user minicomputer, using microcode to interpret a
byte-code implementation language. At approximately the same time,
Richard Greenblatt began work on a different hardware and
instruction-set design at MIT.
Eventually, a dialect of Interlisp known as Interlisp-D became
available on the D-series machines manufactured by Xerox---the Dorado,
Dolphin, and later the Dandelion. An upward-compatible extension of
MacLisp called ZetaLisp became available on the early MIT Lisp
machines. Commercial Lisp machines from Xerox, Lisp Machines, Inc.
(LMI), and Symbolics, Inc., were on the market by 1981.
During the mid-1970's, ZetaLisp began to expand towards a much fuller
language. Sophisticated lambda-lists, SETF, multiple values,
packages, and structures like those in @clisp\ are the results of
early experimentation with programming styles by the Lisp machine
group; these styles found their way into MacLisp.
Around 1980, Scott Fahlman and others at CMU began work on a Lisp to
run on the SPICE (Scientific Personal Integrated Computing
Environment) workstation. One of the goals of the project was to
design a simpler dialect than ZetaLisp.
The Macsyma group at MIT began a project during the late 1970's called
the New Implementation of Lisp (NIL) for the Vax. One of the stated
goals of the NIL project was to fix many of the historic, but
annoying, problems with Lisp while retaining compatibility with
MacLisp. About the same time, a research group at Stanford University
and Lawrence Livermore National Laboratory began the design of a Lisp
to run on the S-1~Mark~IIA supercomputer. S-1~Lisp, never completely
functional, was the test bed for adapting advanced compiler techniques
to Lisp implementation. Eventually the S-1 and NIL groups
collaborated.
The first efforts towards Lisp standardization were Standard Lisp and
Portable Standard Lisp (PSL). In 1969, Anthony Hearn and Martin Griss
defined Standard Lisp as a subset of Lisp~1.5 and other dialects to
transport REDUCE, a symbolic algebra system. Portable Standard Lisp
(PSL) was designed tp provide more control over the environment and
the compiler.
At the end of the 1970's, PSL ran on about a dozen different
computers. PSL and Franz Lisp---a MacLisp-like dialect for Unix
machines---were the first examples of widely available Lisp dialects
on multiple hardware platforms.
One of the most important developments in Lisp occurred during the
second half of the 1970's: Scheme. Scheme, designed by Gerald J.
Sussman and Guy L. Steele Jr., is a simple dialect of Lisp whose
design brought to Lisp some of the ideas from programming language
semantics developed in the 1960's. Sussman was one of the prime
innovators behind many other advances in Lisp technology from the late
1960's through the 1970's.
The major contributions of Scheme were lexical scoping, first-class
functions and continuations, and simplified syntax (no separation of
values and functions). Some of these contributions made a large impact
on the design of @clisp.
In the mid-1970's object-oriented programming concepts started to make
a strong impact on Lisp' At MIT, Flavors, an object-oriented
programming system with multiple inheritance patterned after
Smalltalk was developed and integrated into Lisp machines. At Xerox,
the experience with Smalltalk and KRL led to the development of LOOPS.
These systems influenced the design of the Common Lisp Object System
(CLOS).
In 1980 Symbolics and LMI were developing ZetaLisp; stock-hardware
implementation groups were developing NIL, Franz Lisp, and PSL; Xerox
was developing InterLisp; and the SPICE project at CMU was developing
a MacLisp-like dialect of Lisp called SpiceLisp.
In April 1981, after a DARPA-sponsored meeting concerning the
splintered Lisp community, Symbolics, the SPICE project, the NIL
project, and the S-1~Lisp project joined together to define @clisp.
This effort was led by Scott Fahlman, Daniel Weinreb, David Moon, Guy
L. Steele Jr., and Richard Gabriel. @clisp\ was designed as a
description of a family of languages. The primary influences on
@clisp\ were ZetaLisp, MacLisp, NIL, S-1~Lisp, Spice Lisp, and Scheme.
{\it Common Lisp the Language\/} is a description of that design. Its
semantics were intentionally underspecified in places where it was
felt that a tight specification would overly constrain @clisp\
research and use. However, industrial use of @clisp\ mandates
stricter standardization for portability. Left out of the original
@clisp\ were an object-oriented programming system, a condition
system, iteration facilities, and a way to handle large character
sets. Therefore, a new language specification, this document, was
developed by the X3J13 committee.
\endsubSection%{History}
∂18-Apr-89 2137 Quinquevirate-mailer issues that will probably pass in June?
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Apr 89 21:37:00 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA04753; Tue, 18 Apr 89 10:48:41 PDT
Message-Id: <8904181748.AA04753@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA04753; Tue, 18 Apr 89 10:48:41 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 Apr 89 13:44
To: quinquevirate@sail.stanford.edu
Subject: issues that will probably pass in June?
This is the list I promised. At Larry's suggestion, I will try to include
hooks for these issues, though not exact wording, in the standard before
the June meeting. Any suggestions for additions or deletions?
kc
*****************************************************************************
Issues that will probably come up and pass in some form in June:
*****************************************************************************
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE 433
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
Issue: DYNAMIC-EXTENT-FUNCTION
Edit history: 04-Apr-89, Version 1 by Loosemore
Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
Edit history: 06-Mar-89, Version 1 by Pitman
Issue: HASH-TABLE-SIZE
Edit history: Version 1, 20-Mar-89, by Moon
Issue: LOAD-TRUENAME
11-Apr-89, Version 4 by Pitman (merge Moon's v3 comments)
Issue: PATHNAME-COMPONENT-CASE
22-Mar-89, Version 2 by Moon, update and rewrite
Issue: PATHNAME-COMPONENT-VALUE
Edit history: Version 1, 20-Mar-89, by Moon
Issue: PATHNAME-SUBDIRECTORY-LIST 463
23-Mar-89, Version 4 by Pitman ([hopefully] just fix typos)
Issue: PATHNAME-SYNTAX-ERROR-TIME
Edit history: 07-Jul-88, Version 1 by Pitman
Issue: PATHNAME-WILD
06-Oct-88, Version 2 by Pitman
Issue: PRETTY-PRINT-INTERFACE
Version 4, 22-Mar-89 by Waters
Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
Edit history: 26-Jan-89, Version 1 by Pitman
Issue: READ-CASE-SENSITIVITY
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Issue: CLOS-MACRO-COMPILATION 454
V3, 21 Mar 1989, Sandra Loosemore (fix error language)
Issue: COMPILE-ENVIRONMENT-CONSISTENCY 312 418
V5, 22 Mar 1989, Sandra Loosemore (fix error language)
Issue: COMPILE-FILE-SYMBOL-HANDLING 455
V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
Issue: COMPILED-FUNCTION-REQUIREMENTS 443
V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)
Issue: CONSTANT-FUNCTION-COMPILATION
Edit History: V1, 22 Mar 1989, Sandra Loosemore (split from issue
CONSTANT-COMPILABLE-TYPES)
Issue: DEFCONSTANT-NOT-WIRED 457
13 Mar 1989, V6 by Sandra Loosemore (start over)
Issue: MACRO-CACHING 449
11-Mar-89, Version 2 by Loosemore (add discussion)
Issue: PROCLAIM-ETC-IN-COMPILE-FILE 318
13 Mar 89, V4 by Sandra Loosemore (discussion)
Issue: SYNTACTIC-ENVIRONMENT-ACCESS 461
Version 6, 23-Mar-89, Sandra Loosemore (more revisions)
Issue: CONFORMANCE-POSITION
Issue: EXTRA-RETURN-VALUES
∂19-Apr-89 0707 Quinquevirate-mailer History Section (1.1)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 07:07:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 580757; Tue 18-Apr-89 17:48:19 EDT
Date: Tue, 18 Apr 89 17:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: History Section (1.1)
To: quinquevirate@sail.stanford.edu
In-Reply-To: <8904170529.AA00492@challenger>
Message-ID: <19890418214816.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 16 Apr 89 22:29:39 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Here is my current rewrite of the history section (1.1).
This is mostly good. It's so terse that it reads rather choppily, but
since that's intentional, I won't complain.
I have a few comments (all nit picking I think):
One response to the address space problem was the Lisp machine, a
special-purpose computer designed to run Lisp programs. The other
response was to use computers with address spaces larger than 18~bits,
such as the Digital Equipment Corporation Vax and the S-1~Mark~IIA.
I think the word "general-purpose" is missing from the third line. The
Lisp machine is also a computer with address space larger than 18 bits.
"Lisp Machine" is usually spelled with both words capitalized.
"VAX" is usually spelled in all caps.
I'm obliged to point out that the word "ZetaLisp" is a registered
trademark of Symbolics, Inc., so this shouldn't say that other
organizations (such as LMI and MIT) were also developing something
called "ZetaLisp". I don't remember what it was called at MIT,
perhaps just "Lisp Machine Lisp."
During the mid-1970's, ZetaLisp began to expand towards a much fuller
ZetaLisp didn't exist until 1980 or 1981, and Lisp Machine Lisp began
to expand in 1976 or 1977, so I would say the late 1970's rather than
the mid 1970's.
In the mid-1970's object-oriented programming concepts started to make
a strong impact on Lisp' At MIT, Flavors, an object-oriented
programming system with multiple inheritance patterned after
Smalltalk was developed and integrated into Lisp machines. At Xerox,
Maybe this is late 1970's too, I'm not sure. More to the point, I'd
change the word order since the multiple inheritance as the part that
was -not- patterned after Smalltalk:
At MIT, Flavors, an object-oriented programming system patterned
after Smalltalk but with multiple inheritance, was developed and
integrated into Lisp Machines.
I agree with this paragraph but there is something wrong with the way
the 3rd sentence flows into the 4th sentence. I haven't been able to
figure out quite how to rework it, but the outline is:
CLtL had this goal
The new language has a different goal
These are the differences
Maybe someone else can take a stab at it.
{\it Common Lisp the Language\/} is a description of that design. Its
semantics were intentionally underspecified in places where it was
felt that a tight specification would overly constrain @clisp\
research and use. However, industrial use of @clisp\ mandates
stricter standardization for portability. Left out of the original
@clisp\ were an object-oriented programming system, a condition
system, iteration facilities, and a way to handle large character
sets. Therefore, a new language specification, this document, was
developed by the X3J13 committee.
∂19-Apr-89 0849 Quinquevirate-mailer History Section (1.1)
To: Quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Thanks, Dave, for your comments. When I stop reading OOPSLA papers
(next week) I will get back in the saddle. Two questions for the
whole group, assuming accuracy is acceptable at some point:
1. Is the section too terse and if so how much real estate
are we willing to spend on this section? The same facts
that you now see were distilled from a section 50% longer
than what you're reading. That might have been to steep
a shrinkage.
2. Do we want such a section at all? Is there a precedent?
3. Should we simply start at the April 1981 date and talk only
about the Common Lisp process?
About OOPSLA, I would guess that the worst 5 papers submitted to the
last L&FP would be in the 50% percentile of the papers submitted to OOPSLA.
-rpg-
∂20-Apr-89 0900 Quinquevirate-mailer Sections 2.3 and 2.5
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89 09:00:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 581860; Thu 20-Apr-89 12:00:01 EDT
Date: Thu, 20 Apr 89 12:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Sections 2.3 and 2.5
To: quinquevirate@sail.stanford.edu
Message-ID: <19890420160017.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Sections 2.3 and 2.5 are marked as done, but here are some comments
from one of our CLOS implementors, who has just done a very careful
reading of the 5.10 versions of 2.3, 2.4, and 2.5. This message is
mainly to KC, but I thought all the qinquevirate should be copied.
RPG in particular might have comments.
I [still Moon] think these comments fall into two categories. One is
editorial problems introduced by reorganizing the text that was in
88-002R and those are straightforward to handle. The other is problems
with the Common Lisp language caused by the metaobjects portion of CLOS
not getting done on time. Right now we have some small inconsistencies
in the language due to this. Possible approaches would be to
exterminate anything that mentions metaobjects, or to incorporate some
selected portions of the beginning of chapter 3 into the standard, or to
flag some portions of the specification as being a framework for future
extensions that shouldn't be expected to make sense standing on its own
without those extensions. I currently favor the third course, partly
because I think it is the easiest. The comments below may not completely
flag all the places where this should be done; if the drafting committee
decides this is the right course of action, I (or Dick?) can go through
and flag all such places.
p.2-3, para.3: Without meta objects one can't create anonymous classes
and improper class names, so much of this paragraph is currently
irrelevant. Keep the first two sentences and the last sentence, delete
the rest. [I think we should keep it anyway, but flag it as a framework
for future extensions --Moon]
p.2-4, para.3,4: Again the stuff about metaclasses is not relevant to
the current metaobject-free standard.
p.2-5, bullet 3: changing "is shared by instances" to
"is shared by all instances" would be clearer.
p.2-5: Delete the 3-line inheritance section. This section has been
reorganized into nonexistence.
p.2-5: Inheritance of Class Options should come after the class
precedence list section.
p.2-9, Redefining Classes, Third paragraph: The CLOS spec says when
slots aren't updated, X3J13 says when they are updated. X3J13 doesn't
mention anything about changes to ordering. [How come this spec.
doesn't say exactly the same thing as 88-002R here? --Moon]
In several of these paragraphs, references are made to the "old class"
and the "new class". It would be clearer to say "the old class
definition" and "the new class definition" since it's still the same
class object after the redefinition.
p.2-24: If there's no MOP, then "These procedures can be customized ..."
should go away, as well as the last sentence of the next paragraph.
p.2-26: It would be nice if it said "Every generic function is an
instance of the class standard-generic-function or one of its
subclasses". [But I don't think that's true, at least after
metaobjects are put in. --Moon]
∂22-Apr-89 1136 Quinquevirate-mailer Sections 2.3 and 2.5
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Apr 89 11:36:39 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA15597g; Sat, 22 Apr 89 11:36:36 PDT
Received: by challenger id AA01737g; Sat, 22 Apr 89 11:36:27 PDT
Date: Sat, 22 Apr 89 11:36:27 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904221836.AA01737@challenger>
To: quinquevirate@sail.stanford.edu
Subject: Sections 2.3 and 2.5
Of the three approaches Moon suggests, I favor a combination of
bringing some stuff into the main specification from the prototype
chapter 3 and flagging the rest as places for future extension.
I feel that the largest exposures we have are readers (but not
writers) for some things like these (this list suggested by Jonl):
class-direct-supers, class-direct-subclasses, class-direct-slots,
class-slots, class-direct-methods, class-precedence-list,
class-forward-referenced-supers, class-no-of-instance-slots,
method-function, method-generic-function, method-arglist,
method-qualifiers, method-specializers, generic-function-name,
generic-function-methods, generic-function-discriminator-code,
generic-function-lambda-list, slotd-name, slotd-allocation,
slotd-initform, slotd-initargs, and slotd-type.
Also we are exposed on the inability to make methods for add-method to
use. These are the places where I would consider trying move something
into the main specification.
Someone writes:
``p.2-3, para.3: Without meta objects one can't create anonymous
classes and improper class names, so much of this paragraph is
currently irrelevant. Keep the first two sentences and the last
sentence, delete the rest. [I think we should keep it anyway, but
flag it as a framework for future extensions --Moon]''
Hm, I thought CLASS-NAME was a SETFable place, as was FIND-CLASS, but
I guess that isn't true as it currently stands.
``p.2-4, para.3,4: Again the stuff about metaclasses is not relevant to
the current metaobject-free standard.''
Well, there are various metaclasses now (structure-class and
standard-class), and there are some places that talk about compatible
metaclasses. I can't believe it's reasonable to flush all mention of
metaclasses because you cannot create them. (Actually, you can, but it
isn't likely that you can do anything useful with them. For example,
you can do (defclass random-metaclass (standard-class)) and then
proceed to make instances of it which are hardly distinguishable from
ordinary standard classes.)
``p.2-5, bullet 3: changing "is shared by instances" to
"is shared by all instances" would be clearer.''
This is fine. Kathy, can you do this?
``p.2-5: Delete the 3-line inheritance section. This section has been
reorganized into nonexistence.
p.2-5: Inheritance of Class Options should come after the class
precedence list section.''
Ok. Kathy, can you do this?
``p.2-9, Redefining Classes, Third paragraph: The CLOS spec says when
slots aren't updated, X3J13 says when they are updated. X3J13 doesn't
mention anything about changes to ordering. [How come this spec.
doesn't say exactly the same thing as 88-002R here? --Moon]''
I don't quite get this. I have the Feb 14 X3J13 draft here (my March 21
draft is at work), and both the Feb 14 draft and 88-002R say this:
``Note that redefining a class may cause slots to be added or deleted.
If a class is redefined in a way that changes the set of local slots
accessible in instances, the instances will be updated. It is
implementation dependent whether instances are updated if a class is
redefined in a way that does not change the set of local slots
accessible in instances.''
On the other hand, this paragraph appears on page 2-47 not 2-9, so it's
hard to tell whether we are all talking about the same thing.
``In several of these paragraphs, references are made to the "old class"
and the "new class". It would be clearer to say "the old class
definition" and "the new class definition" since it's still the same
class object after the redefinition.''
I think there is ample distinction made in the first paragraph of this section
between the class object and the class. This section and others like it
are difficult enough to understand without extra words like ``definition''
being thrown in where that doesn't really aid understanding. Consider how
you would rewrite this using ``definition'':
``The value of a slot that is specified as shared both in the old class
and in the new class is retained. If such a shared slot was unbound
in the old class, it will be unbound in the new class. Slots that
were local in the old class and that are shared in the new class are
initialized. Newly added shared slots are initialized.''
Here is a try:
``The value of a slot that is specified as shared both by the old
class definition and by the new class definition is retained. If such
a shared slot was unbound in the class specified by the old
definition, it will be unbound in the class specified by the new
definition. Slots that were specified as local by the old class
definition and that are specified as shared by the new class are
initialized. Newly added shared slots are initialized.''
I'm not sure that this slightly more precise paragraph says anything
more than the original, and it is a lot harder to understand.
Finally, the classes might be EQ, but they are not equal as classes.
(1 2 3) and (a b c d e) might be EQ, but one is the old list and the
other is the new list, if one was derived from the other via
replacement.
-rpg-
∂23-Apr-89 2053 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Apr 89 20:53:19 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA16143g; Sun, 23 Apr 89 20:52:37 PDT
Received: by challenger id AA02650g; Sun, 23 Apr 89 20:52:30 PDT
Date: Sun, 23 Apr 89 20:52:30 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904240352.AA02650@challenger>
To: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
Subject: Function constants
I haven't followed the discussion on constants, so this might
repeat some material.
The first question is what it means to be a function constant. It
doesn't mean a constant function, which is a function that returns the
same thing every time it's called. But, does it mean that it has
an alterable environment?
(let ((a (list 1 2 3)))
(labels ((f (x n) (+ x (nth n a)))
(g (x n) (setf (nth n a) x)))
...))
Is G suitable as a function constant? How about F? I happen to think
both are suitable as function constants, and the intuitive behavior
should be enforced. The reason is that there is no structural
modification that is being done to the functions to alter them.
That it, there is nothing like
(setf (<some-part-of> F) <new-value>)
that is taking place, just the normal function invocation.
The second question is how do you dump such a thing as a function.
Well, if your compiler can compile-file this you are part way there:
(defun f (x y) (+ x y))
That is, you can dump and load functions.
The objection might be that a non-null environment is needed. If you
cannot compile-file this then you are out of conformance anyway:
(let ((a (list 1 2 3)))
(defun (x n) (+ x (nth n a)))
(defun g (x n) (setf (nth n a) x)))
So the remaining problem is how to dump ``code vectors.'' This is
simple if you have position-independent code, because then you just
dump the bits as if it were a bit-vector. The question is whether we
wish to support machines that have no such thing as position
independent code or do we wish to require implementations to keep
relocation information around (which they will anyway if they can
garbage collect code and compact the space). [Note that the
environments have to be put in something other than a readonly space,
one that the GC sees.]
There are possibly some other problems, such as the material that
might appear as additional information in something like a procedure
header. For example, links to other functions or weird system- or
machine-dependent information. I think we have to assume (and make it
absolutely clear) that we can only specify compilation when the
compiled code is being loaded into a Common Lisp that is identical to
the one doing the compiling (See the next paragraph.)
An alternative to the function constant problem is as follows: We
state that compilation is meaningful in only two situations: COMPILE
in an image with no dumping allowed and COMPILE-FILE in a fresh Lisp
where the compilation will not load any compiled code, where only one
compilation unit will be compiled, and where the result will be loaded
in a copy of the same fresh Lisp that was used to do the compilation.
Calls to COMPILE are allowed in the second scenario. (That is, you
start a lisp, compile-file, quit, start afresh that same Lisp, load.)
In these two cases we can allow the free use of functions as constants
because either there is no need to dump stuff, or else all the source
code that is needed can be made available. That is, in this case, all
the functions that could be constants have either had their source
examined and saved by the very compiler doing all the work or else are
functions in the Common Lisp package, which can be dumped by name.
This case is a little restrictive, but this would be a conservative
case for which we are able to specify the meaning of compilation. Some
implementations might be able to handle less restrictive cases, but it
isn't required.
-rpg-
∂24-Apr-89 0640 Quinquevirate-mailer Re: Function constants
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Apr 89 06:39:42 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18845; Mon, 24 Apr 89 07:39:48 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10255; Mon, 24 Apr 89 07:39:45 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904241339.AA10255@defun.utah.edu>
Date: Mon, 24 Apr 89 07:39:43 MDT
Subject: Re: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
Cc: cl-compiler@sail.stanford.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Sun, 23 Apr 89 20:52:30 PDT
[CC'ed to cl-compiler.]
> Date: Sun, 23 Apr 89 20:52:30 PDT
> From: Richard P. Gabriel <rpg@lucid.com>
>
> The first question is what it means to be a function constant. It
> doesn't mean a constant function, which is a function that returns the
> same thing every time it's called. But, does it mean that it has
> an alterable environment?
I would define a function constant as an object of type FUNCTION that
appears as a quoted or self-evaluating form. (This is quite distinct
from a FUNCTION special form.)
> The second question is how do you dump such a thing as a function.
> Well, if your compiler can compile-file this you are part way there:
>
> (defun f (x y) (+ x y))
>
> That is, you can dump and load functions.
No, this is a FUNCTION special form, not a function constant. What
you are dumping and loading is code which will create a function
object when executed, not the function object itself.
> So the remaining problem is how to dump ``code vectors.'' This is
> simple if you have position-independent code, because then you just
> dump the bits as if it were a bit-vector. The question is whether we
> wish to support machines that have no such thing as position
> independent code or do we wish to require implementations to keep
> relocation information around (which they will anyway if they can
> garbage collect code and compact the space). [Note that the
> environments have to be put in something other than a readonly space,
> one that the GC sees.]
I agree this is the main question from an implementation point of
view. I know that for some implementations (i.e., UCL), this
requirement would be a major headache.
I'd argue that since this isn't compatible with current practice, and
is a lot of work to implement, that it probably isn't a good thing to
require unless doing so would provide some desperately needed
functionality that is now missing from the language. I question
whether the need for the ability to dump function constants is really
all that great. I'm having a hard time even coming up with a
realistic example that could not also be handled using
LOAD-TIME-VALUE.
There is also a problem with dumping closures that you didn't mention.
Unless the object is looked up "by name" by the loader, the dump/load
process inherently creates a copy of the original object. Closure
environments are no exception to that rule, which could lead to some
unexpected behavior.
> An alternative to the function constant problem is as follows: We
> state that compilation is meaningful in only two situations: COMPILE
> in an image with no dumping allowed and COMPILE-FILE in a fresh Lisp
> where the compilation will not load any compiled code, where only one
> compilation unit will be compiled, and where the result will be loaded
> in a copy of the same fresh Lisp that was used to do the compilation.
> Calls to COMPILE are allowed in the second scenario. (That is, you
> start a lisp, compile-file, quit, start afresh that same Lisp, load.)
>
> In these two cases we can allow the free use of functions as constants
> because either there is no need to dump stuff, or else all the source
> code that is needed can be made available. That is, in this case, all
> the functions that could be constants have either had their source
> examined and saved by the very compiler doing all the work or else are
> functions in the Common Lisp package, which can be dumped by name.
We've already said that it's OK for function constants to appear in
code processed by COMPILE or EVAL -- issue QUOTE-SEMANTICS said that
constraints on what kinds of objects can appear in constants apply
only to COMPILE-FILE, and that COMPILE never copies.
I'd accept a statement that your second case is the only situation in
which function constants seen by COMPILE-FILE make sense, but saying
that's the only situation in which compilation with COMPILE-FILE is
meaningful seems like it's going way too far in the wrong direction.
Random people picking up the Common Lisp standard would get a very bad
impression of the language from seeing a restriction like that, and
it's certainly not consistent with current practice.
-Sandra
-------
∂24-Apr-89 1424 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Apr 89 14:24:47 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00240g; Mon, 24 Apr 89 09:20:34 PDT
Received: by challenger id AA03231g; Mon, 24 Apr 89 09:18:58 PDT
Date: Mon, 24 Apr 89 09:18:58 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904241618.AA03231@challenger>
To: sandra%defun@cs.utah.edu
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 24 Apr 89 07:39:43 MDT <8904241339.AA10255@defun.utah.edu>
Subject: Function constants
``No, this is a FUNCTION special form, not a function constant. What
you are dumping and loading is code which will create a function
object when executed, not the function object itself.''
I know, but if you cannot dump anything like a function in any context,
you're really losing. (I don't believe in smiley faces, but there should
have been one there.)
``I agree this is the main question from an implementation point of
view. I know that for some implementations (i.e., UCL), this
requirement would be a major headache.''
I'll challenge this. I think only KCL might not be able to do it.
Is UCL Utah Common Lisp?
``I'd argue that since this isn't compatible with current practice....''
If no one can do it because it is too hard to implement, how can it be
incompatible? You mean that it isn't part of current practice.
``I question whether the need for the ability to dump function
constants is really all that great. I'm having a hard time even
coming up with a realistic example that could not also be handled
using LOAD-TIME-VALUE''
This is an interesting point. I actually almost never use constants
of any sort except for NIL and numbers. Maybe someone could make a
little list of the uses of constants aside from numbers and lists -
maybe having anything but those around is worthless.
``We've already said that it's OK for function constants to appear in
code processed by COMPILE or EVAL -- issue QUOTE-SEMANTICS said that
constraints on what kinds of objects can appear in constants apply
only to COMPILE-FILE, and that COMPILE never copies.''
``I'd accept a statement that your second case is the only situation in
which function constants seen by COMPILE-FILE make sense, but saying
that's the only situation in which compilation with COMPILE-FILE is
meaningful seems like it's going way too far in the wrong direction.''
Well, here's an interesting point. I think it is important for our
specification of compiler semantics to be the same regardless of the
context - otherwise we are specifying too many languages. Already we
see arguements that COMPILE and COMPILE-FILE should be different.
I am trying to avoid a situation in which we go to great lengths to
define a language - Common Lisp - and then we turn around and say,
``heh, now if you want to write programs and compile them, here are
the rules: if you're going to compile things this way, you can do this,
but you can't do that; if you're going to compile things this other way,
here's what you have to do....''
The issue is to make sure there are at most two languages defined -
1. Common Lisp in Plato's heaven
2. Common Lisp that a compiler understands
I think having a restrictive set of scenarios in which any conforming
Common Lisp program is guaranteed to have the semantics described in
the specification is vastly better than a series of different
languages. I think we have to be explicit in stating that these
restrictive scenarios are ones in which we cannot uniformly state what
every implementation can do uniformly, but that the intention is that
every implementation will try to make the same compilable language
work in all compilation scenarios, not just the ones laid out.
``Random people picking up the Common Lisp standard would get a very bad
impression of the language from seeing a restriction like that, and
it's certainly not consistent with current practice.''
I think they will like less the specification of a number of
languages. And it is consistent, because it is a subset - again, you
mean it isn't the same as current practice. If you want to give the
best impression, then let's just say that there is Common Lisp, and
the compiler is allowed to copy or not allowed to copy in certain
situations, and that otherwise any compilation is
semantics-transparent - any implementation that doesn't provide this
is out of conformance.
-rpg-
∂25-Apr-89 0723 Quinquevirate-mailer Re: Function constants
Received: from cs.utah.edu ([128.110.4.21]) by SAIL.Stanford.EDU with TCP; 25 Apr 89 07:23:33 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA27636; Tue, 25 Apr 89 08:23:28 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11014; Tue, 25 Apr 89 08:23:26 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904251423.AA11014@defun.utah.edu>
Date: Tue, 25 Apr 89 08:23:25 MDT
Subject: Re: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Mon, 24 Apr 89 09:18:58 PDT
> Date: Mon, 24 Apr 89 09:18:58 PDT
> From: Richard P. Gabriel <rpg@lucid.com>
>
> I am trying to avoid a situation in which we go to great lengths to
> define a language - Common Lisp - and then we turn around and say,
> ``heh, now if you want to write programs and compile them, here are
> the rules: if you're going to compile things this way, you can do this,
> but you can't do that; if you're going to compile things this other way,
> here's what you have to do....''
I agree, but it seems like the damage was done when we accepted
proposal QUOTE-SEMANTICS:NO-COPYING. The effect of that proposal is
to make the requirements for COMPILE-FILE more restrictive than the
ones for EVAL and COMPILE, so we are in fact dealing with two
specifications. (All we are trying to deal with as far as function
constants are concerned is COMPILE-FILE.)
-Sandra
-------
∂25-Apr-89 0756 Quinquevirate-mailer No-copying
To: sandra%defun@CS.UTAH.EDU, quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Ok, so let's hear your argument about no-copying. I have to admit that
I had a lot of difficulty understanding the writeup of this proposal.
-rpg-
∂25-Apr-89 0823 Quinquevirate-mailer Re: No-copying
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Apr 89 08:23:31 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA29113; Tue, 25 Apr 89 09:23:32 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11044; Tue, 25 Apr 89 09:23:30 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904251523.AA11044@defun.utah.edu>
Date: Tue, 25 Apr 89 09:23:29 MDT
Subject: Re: No-copying
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: sandra%defun@cs.utah.edu, quinquevirate@SAIL.Stanford.EDU
In-Reply-To: Dick Gabriel <RPG@SAIL.Stanford.EDU>, 25 Apr 89 0756 PDT
I don't know what more I can say about issue QUOTE-SEMANTICS -- it
seems like we've already beaten it to death. I guess people decided
that freeing COMPILE and EVAL from restrictions on what kinds of
objects can appear as constants was more important to them than
maintaining consistency with file compilation.
-Sandra
-------
∂25-Apr-89 0839 Quinquevirate-mailer Re: Function constants
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Apr 89 08:38:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 584260; Tue 25-Apr-89 11:38:32 EDT
Date: Tue, 25 Apr 89 11:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Function constants
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8904251423.AA11014@defun.utah.edu>
Message-ID: <19890425153849.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 25 Apr 89 08:23:25 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Mon, 24 Apr 89 09:18:58 PDT
> From: Richard P. Gabriel <rpg@lucid.com>
>
> I am trying to avoid a situation in which we go to great lengths to
> define a language - Common Lisp - and then we turn around and say,
> ``heh, now if you want to write programs and compile them, here are
> the rules: if you're going to compile things this way, you can do this,
> but you can't do that; if you're going to compile things this other way,
> here's what you have to do....''
I agree, but it seems like the damage was done when we accepted
proposal QUOTE-SEMANTICS:NO-COPYING. The effect of that proposal is
to make the requirements for COMPILE-FILE more restrictive than the
ones for EVAL and COMPILE, so we are in fact dealing with two
specifications.
I don't think it was QUOTE-SEMANTICS:NO-COPYING that did the damage. I
think the damage occurred when COMPILE-FILE itself was admitted into the
language. I see no chance of COMPILE-FILE ever being able to imitate
everything that can be done with EVAL, simply because COMPILE-FILE deals
with two copies of Lisp instead of one. You don't have to do anything
involving constants to see differences between EVAL and COMPILE-FILE.
Macros are enough.
I don't think anyone wants to remove COMPILE-FILE, so instead I think
we have to specify a minimal set of restrictions on what programs can
do -at- -compile- -time- to make them compilable by COMPILE-FILE. This
of course does not restrict what they can do at run time, which can
include calling COMPILE. I don't see any analogy between COMPILE and
COMPILE-FILE, other than that they both call MACROEXPAND and both call
some common subroutine for making machine language instructions. I
think the compiler commitee has been doing a pretty good job recently
of finding a minimal set of restrictions. Dick, I agree with your
contention that the set of restrictions should be minimal, but not that
it should be empty, nor that it should be phrased in a way that is
independent of the idea of compiling or loading a file.
∂25-Apr-89 0859 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 08:59:30 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA01578g; Tue, 25 Apr 89 08:58:29 PDT
Received: by challenger id AA04612g; Tue, 25 Apr 89 08:58:22 PDT
Date: Tue, 25 Apr 89 08:58:22 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904251558.AA04612@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 25 Apr 89 11:38 EDT <19890425153849.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Function constants
I believe that there are some scenarios in which EVAL and COMPILE-FILE
have the same behavior. My question (it's actually a question, not a
disguised contention) is whether these scenarios can be captured with
a simple description, and if so whether that description is
unrestrictive enough.
For example, the description I propose is:
1. A well-formed compilation unit has all type and macro definitions
first, then all function definitions, and then all executable expressions.
2. You must use a fresh Lisp when compile-filing, and you cannot
invoke load or anything but trivial (or *no*) EVAL-WHEN's.
3. You must load a compile-filed file into a fresh copy of the same Lisp.
If you do these, the semantics of EVAL and compile-file on that compilation
unit is the same (?).
Now, once you've described this very safe situation to the user, you
can *go* *on* to say what other restrictions would apply if you relaxed
these conditions - what if you load, what if you do have hairy EVAL-WHEN's.
The idea is that some users will want to know how to construct totally
reliable compilable files without having to learn obscure rules. We
can express these obscure rules, but I also want to see a simple
prescription that does not limit the semantics of Common Lisp.
If the obscure rules are not too obscure, then it is probably best to
just go with them, but I thinkwe currently skate close to the edge with
the obscure rules (this is a compliment, also, to Sandra: we could easily have
gone off the deep end, but didn't.)
-rpg-
∂25-Apr-89 0913 Quinquevirate-mailer Function constants
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Apr 89 09:13:08 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 584302; Tue 25-Apr-89 12:11:48 EDT
Date: Tue, 25 Apr 89 12:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: <8904251558.AA04612@challenger>
Message-ID: <19890425161207.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 25 Apr 89 08:58:22 PDT
From: Richard P. Gabriel <rpg@lucid.com>
I believe that there are some scenarios in which EVAL and COMPILE-FILE
have the same behavior. My question (it's actually a question, not a
disguised contention) is whether these scenarios can be captured with
a simple description, and if so whether that description is
unrestrictive enough.
For example, the description I propose is:
1. A well-formed compilation unit has all type and macro definitions
first, then all function definitions, and then all executable expressions.
2. You must use a fresh Lisp when compile-filing, and you cannot
invoke load or anything but trivial (or *no*) EVAL-WHEN's.
3. You must load a compile-filed file into a fresh copy of the same Lisp.
If you do these, the semantics of EVAL and compile-file on that compilation
unit is the same (?).
But the argument to EVAL is a form, not a file. So I don't see how you can
even begin to compare the two. There is no concept of compilation units
when dealing with EVAL. I don't think I'm just obnoxiously nitpicking
here, although maybe there is a different way to say what you're saying that
will straighten me out. Could it be that you not talking about EVAL at all,
but about LOAD, and not talking so much about what Common Lisp programs do
as about how to construct files containing Common Lisp programs?
∂25-Apr-89 1325 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 13:25:07 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00407g; Tue, 25 Apr 89 13:24:09 PDT
Received: by challenger id AA04931g; Tue, 25 Apr 89 13:24:02 PDT
Date: Tue, 25 Apr 89 13:24:02 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904252024.AA04931@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 25 Apr 89 12:12 EDT <19890425161207.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Function constants
well, it seems that there is a straightforward way to correspond EVAL
and COMPILE-FILE, which I didn't think was necessary to explicate, but
now I will:
Let S = F1,...,Fn be a series of forms. We ignore well-formedness for
the moment, as well as representation, which I will return to.
Let C = {F1,...,Fn}, a compilation unit with those forms in that
order. Let C' be C compiled with compile-file. A fresh Common Lisp
(CLf) when EVALing each element of S in that order should result in
the ``same observable behavior'' that you get by LOADing C' into a
fresh Common Lisp. Observable behavior includes most everything you
can think of except the representation of the functional (and macral)
objects created and the storage allocation/reclamation behavior.
Presumably each Fi is a textual representation of a form. You can
probably approximate this with LOAD for the EVAL case, but I don't
want to exclude typing them in. Unfortunately, we are in a position to
talk only about LOADing a compiled file rather than having some clear
READ-EVAL-PRINT model for compiled objects.
Now, there is clearly some limitation on what the structure of S (or
C) and each Fi can be in order to achieve the ``same behavior,'' and
we probably need to define observable behavior.
An interesting point is the EQness relationship among objects referred
to in S. In all cases, this EQness refers to the EQness of the objects
in CLf, not in any other Common Lisp that might have been involved in
the creation of S, C, or C'. These relationships ought to be derivable
from examination of the text in S. To achieve the same observable
behavior, we might need to consider equivalence classes of behavior
that is defined by those equivalence relations specified by unspecified
behavior. (That is, if our specification of Common Lisp states that
two things may or may not be EQ in some situation, this defines an
equivalence of behavior.)
Part of the same observable behavior is the observed semantics of
programs that run as a result of EVALing the expressions or LOADing
the compiled code. Again, this is up to equivalence classes.
All I'm wondering is how obnoxious the structuring rules and
equivalence relations must be to make this statement of same behavior.
Thus, I am indeed talking about how to structure files for Common Lisp
programs so that the semantics of those programs is the same whether
or not anything like a compiler has seen them.
-rpg-
∂25-Apr-89 1400 Quinquevirate-mailer Re: Function constants
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Apr 89 14:00:27 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA12593; Tue, 25 Apr 89 14:56:35 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11328; Tue, 25 Apr 89 14:56:30 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904252056.AA11328@defun.utah.edu>
Date: Tue, 25 Apr 89 14:56:27 MDT
Subject: Re: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Tue, 25 Apr 89 13:24:02 PDT
This makes sense to me. However, I should point out that there are
really two sets of constraints on the ordering of forms within a file:
those that apply to LOAD (of the source file), and some additional
constraints that apply to COMPILE-FILE.
The first set of constraints exists because of the possibility that
the evaluator might always choose to compile forms before executing
them. This includes things like macro definitions, SPECIAL
proclamations, etc. being available before code that requires them
(including any lexically enclosing FUNCTION special forms) is
executed. I can't find anything in CLtL that says this explicitly,
but I was hoping to see some stronger language in the standard saying
that conforming programs must be structured in such a way that they
would work in a compiled-only implementation.
The second set of constraints has more to do with the file compilation
model and EVAL-WHEN, and is oriented towards making sure that
definitions appearing within a file that are needed to correctly
compile the rest of the file are made in the compile-time environment
as well as at load time.
We could require both sets of requirements to be fulfilled by
conforming programs, though. The real question is whether we view the
semantics of Common Lisp as the semantics of programs that can be
compiled with COMPILE-FILE, or whether we view COMPILE-FILE as a kind
of wart on the language that can process only a restricted subset of
conforming programs. I've always taken the former view, but it
appears that I might be in the minoriy.
-Sandra
-------
∂25-Apr-89 1411 Quinquevirate-mailer Re: Function constants
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Apr 89 14:11:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 584702; Tue 25-Apr-89 17:09:10 EDT
Date: Tue, 25 Apr 89 17:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Function constants
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Richard P. Gabriel <rpg@lucid.com>, quinquevirate@sail.stanford.edu
In-Reply-To: <8904252056.AA11328@defun.utah.edu>
Message-ID: <19890425210929.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 25 Apr 89 14:56:27 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
We could require both sets of requirements to be fulfilled by
conforming programs, though. The real question is whether we view the
semantics of Common Lisp as the semantics of programs that can be
compiled with COMPILE-FILE, or whether we view COMPILE-FILE as a kind
of wart on the language that can process only a restricted subset of
conforming programs. I've always taken the former view, but it
appears that I might be in the minoriy.
The former view is fine with me. My comments were directed more towards
not muddling COMPILE and COMPILE-FILE. In other words, the semantics of
programs that can be compiled with COMPILE-FILE includes that those
programs can call COMPILE on lambda expressions that could not have been
part of the macro expansion of DEFUN forms appearing in a file to be
compiled. That doesn't sound very clear, re-reading it, but from past
mail you should know what I mean. I'm sending this message mainly to
clarify that if you are in the minority, I'm not one of the majority.
∂25-Apr-89 1924 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 19:24:34 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01008g; Tue, 25 Apr 89 19:24:08 PDT
Received: by challenger id AA05566g; Tue, 25 Apr 89 19:24:00 PDT
Date: Tue, 25 Apr 89 19:24:00 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904260224.AA05566@challenger>
To: sandra%defun@cs.utah.edu
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 25 Apr 89 14:56:27 MDT <8904252056.AA11328@defun.utah.edu>
Subject: Function constants
well, I think we're pretty much in synch here. The question of macros
being defined or available before the code that uses them is an
interesting one. It is easy to imagine a programming environment in
which recompilation of all required definitions is done whenever a
macro changes.
So, should we include structuring information? If so, should we only
worry about which definitions should appear before which others? What
do we say about recursive loads and compiles? Presumably the
Lisp-symbol-redefinition covers some bad case; what about readtables
and packages? (I guess something is already said about packages.)
Should we worry about loading compiled files into images in which
compilation already happened, or should we state that we can only
guarantee semantics in the fresh Lisp case?
Regardless of what we do, we need to state that what is actually
sensible in some particular program structure will depend on the
implementation. Possibly we should indicate some things that might
work(?).
What is the resolution of function constants? I prefer these solutions in
this order:
1. Allow them to be used everywhere
2. Allow them to be allowed nowhere, but allow implementations to
extend (that is, leave it undefined).
3. Allow some mixtures in some cases.
-rpg-
∂25-Apr-89 2020 Quinquevirate-mailer Re: Function constants
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Apr 89 20:20:21 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA24885; Tue, 25 Apr 89 21:19:49 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11594; Tue, 25 Apr 89 21:19:46 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904260319.AA11594@defun.utah.edu>
Date: Tue, 25 Apr 89 21:19:44 MDT
Subject: Re: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
Cc: sandra%defun@cs.utah.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM,
quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Tue, 25 Apr 89 19:24:00 PDT
> Date: Tue, 25 Apr 89 19:24:00 PDT
> From: Richard P. Gabriel <rpg@lucid.com>
>
> It is easy to imagine a programming environment in
> which recompilation of all required definitions is done whenever a
> macro changes.
Hmmm. That seems like a programming environment issue, except that
the current version of issue COMPILE-ENVIRONMENT-CONSISTENCY (which we
haven't voted on yet) effectively says that macro definitions don't
affect code once it has been compiled. I think such a programming
environment would be a legitimate extension if users had to set a
magic switch to get this behavior, though.
> So, should we include structuring information? If so, should we only
> worry about which definitions should appear before which others?
I admit to being rather partial to the way this is now handled in the
draft of section 4.2 I've been working on. It talks about what kind
of information is needed by the compiler in the subsection on
compilation semantics, and then the subsection on file compilation
talks about what constructs make information available to the compiler
during processing by COMPILE-FILE. In other words, we've specified a
requirement on implementations. I've kind of been assuming that the
behavior of conforming programs is covered under the part of the
conformance language that says that conforming programs have to depend
on the semantics of the language as described in the standard, and
that no additional requirements on conforming programs were necessary
as far as compilability is concerned.
> What do we say about recursive loads and compiles?
I think it ought to be allowed and therefore we don't need to say
anything. (I suspect a couple of implementations probably break if
COMPILE-FILE is invoked recursively, but I think that's a bug.)
> Presumably the
> Lisp-symbol-redefinition covers some bad case; what about readtables
> and packages? (I guess something is already said about packages.)
I'm not sure exactly what aspects of readtables and packages you're
referring to here. My writeup for section 4.2 does explicitly mention
manipulation of *READTABLE* and *PACKAGE* as situations where
EVAL-WHEN is useful for making sure that COMPILE-FILE reads the input
file properly, though.
> Should we worry about loading compiled files into images in which
> compilation already happened, or should we state that we can only
> guarantee semantics in the fresh Lisp case?
I don't think there's any problem with specifying the semantics of
loading compiled files into "non-fresh" images. Do you have some
particular aspect in mind that you think is not well-specified?
> What is the resolution of function constants?
Well, unless somebody writes up another proposal, we're stuck with
CONSTANT-FUNCTION-COMPILATION:NO, which means they're OK for COMPILE
and EVAL but the behavior of COMPILE-FILE is unspecified.
-Sandra
-------
∂25-Apr-89 2055 Quinquevirate-mailer Function constants
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 20:55:07 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01116g; Tue, 25 Apr 89 20:54:57 PDT
Received: by challenger id AA05696g; Tue, 25 Apr 89 20:54:50 PDT
Date: Tue, 25 Apr 89 20:54:50 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8904260354.AA05696@challenger>
To: sandra%defun@cs.utah.edu
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 25 Apr 89 21:19:44 MDT <8904260319.AA11594@defun.utah.edu>
Subject: Function constants
Well, I see that your first draft of 4.2 has appeared in my mail (at
SAIL), so I think I should read it before continuing the discussion.
Let me say, though, that I prefer to leave function constants
undefined in all contexts rather than defined in some and undefined in
others.
-rpg-
∂25-Apr-89 2056 Quinquevirate-mailer status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 25 Apr 89 20:56:20 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06267; Tue, 25 Apr 89 20:57:02 PDT
Message-Id: <8904260357.AA06267@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA06267; Tue, 25 Apr 89 20:57:02 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 25 Apr 89 23:49
To: quinquevirate@sail.stanford.edu
Subject: status
I'm working on completing incorporating the issues to the exclusion
of everything else. I've come across several questions and problems
with the issues that I will compile (not eval or compile-file;-)
and get resolution on when I'm done with all of them.
This message is to let you know that there will be more things coming
to you at a faster rate as soon as I complete wading through these
*&&↑%$# issues.
∂01-May-89 1631 Quinquevirate-mailer Re: new cleanups
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 May 89 16:30:54 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 01 MAY 89 16:10:29 PDT
Date: 1 May 89 16:10 PDT
From: masinter.pa@Xerox.COM
Subject: Re: new cleanups
In-reply-to: your message of Fri, 28 Apr 89 18:38:05 MDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: quinquevirate@sail.stanford.edu
Message-ID: <890501-161029-3020@Xerox>
I think we should just make what I think is the only reasonable translation:
"relatively useless" means "is not required by this standard to have any effect"'.
I don't think we need a cleanup issue to do that.
- - - - - -
GV-Info: sandra%defun@cs.utah.edu at 28-Apr-89 17:38:51 from AG
Return-Path: <sandra%defun@cs.utah.edu>
Received: from cs.utah.edu ([128.110.4.21]) by Xerox.COM ; 28 APR 89 17:38:13 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11376; Fri, 28 Apr 89 18:38:09 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA13450; Fri, 28 Apr 89 18:38:06 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904290038.AA13450@defun.utah.edu>
Date: Fri, 28 Apr 89 18:38:05 MDT
Subject: new cleanups
To: masinter.pa
Is the cleanup committee still in business? I'd like to open a new
issue to clarify what *EVALHOOK* is supposed to do in compiled-only
implementations, having just run into the problem while writing a new
evaluator. (CLtL just says it's "relatively useless", whatever that
means.) I'm not sure if this issue falls in the domain of cleanup or
compiler -- I you think I ought to handle it in compiler I'll send
it there.
-Sandra
-------
∂01-May-89 1706 Quinquevirate-mailer Re: new cleanups
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 May 89 17:06:00 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03113; Mon, 1 May 89 18:06:04 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03477; Mon, 1 May 89 18:05:59 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905020005.AA03477@defun.utah.edu>
Date: Mon, 1 May 89 18:05:58 MDT
Subject: Re: new cleanups
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
quinquevirate@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 1 May 89 16:10 PDT
That would be fine, except that there have also been a suggestion
(from Kim Barrett) that perhaps EVALHOOK and friends really ought to
be deprecated, and another one (from Pitman and the Cloe implementors
at Symbolics) that they should either be removed from the language
entirely or somehow marked as being an optional extension, along with
other debugging tools such as STEP and TRACE and the top loop
variables. Certainly any action like that should be done by a vote of
the full committee rather than handled as an editorial change.
Also, I'd like to see a clarification that STEP need not be implemented
in terms of EVALHOOK (CLtL page 323).
-Sandra
-------
∂01-May-89 2229 Quinquevirate-mailer Re: new cleanups
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 May 89 22:29:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 MAY 89 22:28:49 PDT
From: masinter.pa@Xerox.COM
Date: 1 May 89 22:27:46 PDT
Subject: Re: new cleanups
In-reply-to: sandra%defun@cs.utah.edu's message of Mon, 1 May 89 18:05:58
MDT, <8905020005.AA03477@defun.utah.edu>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: masinter.pa@Xerox.COM, quinquevirate@sail.stanford.edu
Message-ID: <890501-222849-4174@Xerox>
I personally am not interested in bringing forward "cleanups" at
this point that would remove STEP and TRACE and the top loop variables.
There's two possibilities: either these are minor clarifications based
on the transition of CLtL from a "user guide" to a "specification",
which we can just handle and propose en masse as "the only reasonable
interpretation of CLtL as a standard", or else these are proposals
for major changes which remove features.
It is a serious mistake to believe that "deprecating" a feature removes
the responsibility of specifying what it does.
∂02-May-89 0604 Quinquevirate-mailer Re: new cleanups
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 May 89 06:04:44 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA28684; Tue, 2 May 89 07:04:50 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA14332; Tue, 2 May 89 07:04:48 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905021304.AA14332@defun.utah.edu>
Date: Tue, 2 May 89 07:04:46 MDT
Subject: Re: new cleanups
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
quinquevirate@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 1 May 89 22:27:46 PDT
I don't believe anybody has been arguing that deprecation is a
substitute for clarification. But in this case, "the only reasonable
interpretation of CLtL" seems to be that users can't rely on EVALHOOK
doing anything meaningful. Does such a feature really have any place
in the language?
-Sandra
-------
∂03-May-89 0302 Quinquevirate-mailer Status as of 5/3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 89 03:01:07 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA13930; Wed, 3 May 89 03:01:54 PDT
Message-Id: <8905031001.AA13930@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA13930; Wed, 3 May 89 03:01:54 PDT
From: chapman%37.975.DEC@decwrl.dec.com
Date: 3 May 89 05:59
To: quinquevirate@sail.stanford.edu
Subject: Status as of 5/3
Following is a status of what's happening with the standard.
Please let me know if this list differs from your expectations.
All clean-up issues that I didn't find problems or questions
with have been included. The next message you get is the list of
issues followed by the files numbers that were changed as a result of each
issue. To find the change that specifically pertains to the issue
you're tracing, look in the source file for "\issue{<issue name>"
or in the hardcopy for "The following is from issue: <issue name>.
The file number to file name translation is in another mail message
you will receive.
What I plan to do next includes removing the Side Effects section
from all the functions that aren't checked out (and then remove it
from that functions that are checked out when they come back to me).
Also I will be including the issues that may be approved in June,
and the issues that I haven't included because of outstanding questions.
I will complete this job when all the sections are checked back to me
again. I will send you the files that have been changed for your review
(so you won't have to go through another complete review if you don't
want to) after I have added the new issues.
I will be creating a list of all places in the standard where error
terminology is needed and suggestions about which type of error
seems to belong there.
I believe we are responsible for at least part of the agenda for the
June meeting. Any suggestions about how we should present what we've
done?
Chapter 1. Introduction
CONTENTS
1.1 Scope, Purpose, and Application RPG has created a new
draft, Moon has reviewed. KC is reviewing
now.
1.2 Organization of the Document Done
1.3 Referenced Publications Done
1.4 Definitions Done
1.5 Compliance KC has created a new
issue to be reviewed and voted on in June or
before. The issue contains all the compliance
information, not just a subset of it, and incorporates
comments from the Germans and information from the
international Pascal standard.
1.6 Language Extensions KC has created a new issue.
Chapter 2. Objects and Types
CONTENTS
2.1 Introduction Done
2.2 Types Moon reviewed, KC
included comments, Moon responded to inclusions,
KC is including responses and sending Moon new copy
to review.
2.3 Classes There have been some
comments about sections 2.3, 2.4, and/or 2.5. These
have been forwarded to RPG.
2.4 Slots Done
2.5 Objects Done
Chapter 3. Object Syntax
CONTENTS
3.1 Character Reader KC is including Loosemore
comments. These will go to Masinter by the end of
this week.
3.2 Object Syntax same as 3.1
Chapter 4. Evaluation and Compilation
CONTENTS
4.1 Evaluation Model Moon reviewed, KC is
including comments. Will return to Moon by the
end of this week.
4.2 Compilation RPG is reviewing Loosemore's
draft.
Chapter 5. Other Topics
CONTENTS
5.1 Errors RPG is rewriting.
5.2 Input/Output Masinter is reviewing.
5.3 Interface with the Programming Environment Masinter is reviewing.
5.4 Generalized Reference Masinter is reviewing.
Chapters 6 and 7. Catalog of Defined Names
CONTENTS
6.1 Introduction KC is including comments,
the RPG will review.
The following list contains the names of groups of functions as they
appear in CLtL, CLOS, and the Condition System documents.
CLOS RPG is reviewing.
PREDICATES Masinter is reviewing.
STRINGS Masinter is reviewing.
SEQUENCES Masinter is reviewing.
LISTS Masinter is reviewing.
NUMBERS Masinter is reviewing.
STRUCTURES GLS is reviewing (in the
US mail to GLS).
SYMBOLS same as STRUCTURES.
HASH-TABLES same as STRUCTURES.
ARRAYS same as STRUCTURES.
TYPES same as STRUCTURES.
DECLARATIONS same as STRUCTURES.
IO Masinter 6/14/89
STREAMS Masinter 6/14/89
FILE Masinter 6/14/89
CONTROL Masinter 6/14/89
PROGRAM Masinter 6/14/89
MISC Masinter 6/14/89
ERRORS RPG 6/14/89
MACROS Moon 6/14/89
PACKAGES Moon 6/14/89
CHARACTERS Moon 6/14/89
EVALUATOR Moon 6/14/89
Glossary KC is including KMP
comments, will send to RPG by the end of this week.
RPG: 1.1, 4.2, 6.1, 5.1, CLOS, Errors, Glossary, proliferating error terms
Masinter: 3.1, 3.2, 5.2, 5.3, 5.4,
PREDICATES, STRINGS, SEQUENCES, LISTS, NUMBERS, IO, STREAMS,
FILE SYSTEM INTERFACE, CONTROL STRUCTURE, PROGRAM STRUCTURE,
MISCELLANEOUS FEATURES
Moon: 2.2, 4.1, MACROS, PACKAGES, CHARACTERS, EVALUATOR
GLS: STRUCTURES, SYMBOLS, HASH-TABLES, ARRAYS, TYPES, DECLARATIONS
∂03-May-89 0402 Quinquevirate-mailer List of issues and which files were changed as a result of each
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 89 04:01:21 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA16965; Wed, 3 May 89 04:02:17 PDT
Message-Id: <8905031102.AA16965@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA16965; Wed, 3 May 89 04:02:17 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 May 89 06:01
To: quinquevirate@sail.stanford.edu
Subject: List of issues and which files were changed as a result of each
Notes:
1. DD means included in standard, files numbers or names that are changed are
listed with the issue.
2. File numbers or names in parens (like under issue FUNCTION-NAME) mean that the file
had a pointer to another file that was actually changed.
3. Any file number in the following list that isn't preceded by a letter
should be preceded by the letter `f'. All file names (like `chapter7')
should be followed by `.tex'.
Issues not in this list on 4/19:
TYPE-OF-UNDERCONSTRAINED:
DECLARE-TYPE-FREE:
TEST-NOT-IF-NOT:
DD -- Issue: ADJUST-ARRAY-DISPLACEMENT
Version 4 by Masinter, 23-Nov-87
ADJUST-ARRAY-DISPLACEMENT -- passed March 88 meeting 230
ADJUST-ARRAY-DISPLACEMENT.TXT;1 -- clarifies what happens when
a displaced array is adjusted.
f028
DD -- Issue: ADJUST-ARRAY-FILL-POINTER
Edit history: 15-Mar-88, Version 1 by Pitman
DD -- ADJUST-ARRAY-FILL-POINTER -- passed June 88 meeting 291
DUA1:[CHAPMAN.FROM-OFFICE]ADJUST-ARRAY-FILL-POINTER.TXT;1 -- clarifies what
happens when an array with a fill pointer is adjusted.
f028
???DD -- Issue: ADJUST-ARRAY-NOT-ADJUSTABLE not complete yet(4/89)
11-Jan-89, Version 4 by Pitman
Adjustable option explanation.
395,029,028
DD -- Issue: APPLYHOOK-ENVIRONMENT
Masinter, 10-Jan-89, Version 2
Remove ENV argument from APPLYHOOK.
257,256
DD -- Issue: AREF-1D
14-Nov-87, Version 7, by Masinter (update discussion)
DD -- AREF-1D -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]AREF-1D.TXT;1 -- new function to access arrays
in row major order.
f750, f599, chapter7, ARRAYS
DD -- Issue: ARGUMENTS-UNDERSPECIFIED
21-Sep-88, Version 4 by Masinter
Specify arguments to functions completely.
371,399,401,406,409,475,598, 502, 550, 552, 553, 554, 557, 558, 592
DD -- Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Version 9, 31-Oct-88, JonL (major re-wording to accommodate
Eliminate distinction between type specifiers for declaration and for
discrimination.
s2200, 689, 043, 661, 751, 752, Chapter7, ARRAYS
DD -- Issue: ASSOC-RASSOC-IF-KEY
23-Nov-87, Version 4 by Masinter
ASSOC-RASSOC-IF-KEY -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]ASSOC-RASSOC-IF-KEY.TXT;1 -- add :key to if, if-not
f056, f544
DD -- Issue: BREAK-ON-WARNINGS-OBSOLETE
8-Apr-89, Version 2 by Masinter (as amended; update discussion)
806, sa300, 252, 805, 841
***Section 5.1 is out, won't do this one until that section comes back from
RPG***
Issue: CLOS-CONDITIONS
10-Mar-89, Version 4 by Pitman (remove unsupported options)
DD -- Issue: CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY
Masinter, 12-Jan-89, Version 2
Glossary, 171, 310, 408
DD -- Issue: CLOSED-STREAM-OPERATIONS
5-Dec-88, Version 5 by Masinter (separate other issues)
Clarify what operations can be performed on a closed stream.
685,630,171,494,428,497,(495,496,498,499,500),451,(270,227,321,246),481,526,226.
DD -- Issue: COLON-NUMBER
Edit history: 22-Oct-87, Version 1 by Pitman
DD -- COLON-NUMBER -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]COLON-NUMBER.TXT;1 -- :<potential number> is an
error.
s3100
DD -- Issue: COMMON-TYPE
Edit history: Version 1, 20-Mar-89, by Moon
s2200, 175, sa300
DD -- Issue: COMPILER-WARNING-STREAM
Version 6 by Masinter, 5-Jun-87, minor formatting
COMPILER-WARNING-STREAM -- passed June 88
compile and compile-file can issue warnings through *error-output*.
f176, f177
DD -- Issue: COMPLEX-ATAN-BRANCH-CUT
Edit history: Version 1, 13-Dec-88, Steele
Replace a formula.
(059), 053
DD -- Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Edit history: Version 1, 14-Sep-88, Moon
Add a contagion rule.
s2200 (now in s6100)
DD -- Issue: COPY-SYMBOL-COPY-PLIST
Edit history: 10-Jan-89, Version 1 by Margolin
192
** need new version of this one
Issue: COPY-SYMBOL-PRINT-NAME
DD -- Issue: DATA-TYPES-HIERARCHY-UNDERSPECIFIED
DATA-TYPES-HIERARCHY-UNDERSPECIFIED -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DATA-TYPES-HIERARCHY-UNDERSPECIFIED.TXT;1 --
make some type disjoint.
s2200, f212
DD -- Issue: DECLARATION-SCOPE:NO-HOISTING
Version 4, JonL, 15-Nov-88 add 2nd proposal; major rewrite.
Clarify scope of declaration at head of special form or lambda expression.
202, Glossary, 356, 528, 229, 283, 444, 232, 234, 235, s4100, 527
DD -- Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89, Pierson (Pitman comments)
Clarify that references to array elements are assumed to satisfy the
exact declared element type.
s2200
DD -- Issue: DECLARE-FUNCTION-AMBIGUITY
#4, 5-Dec-88, Masinter (append Oct x3j13 comments)
Redefine (FUNCTION ...).
202
DD -- Issue: DECLARE-MACROS
DECLARE-MACROS -- passed March 88 meeting
5-Feb-88, Version 3 by Pitman
DUA1:[CHAPMAN.FROM-OFFICE]DECLARE-MACROS.TXT;1 -- don't let macros expand
into declares.
f202, f527
DD -- Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT
30-Sep-88, Version 2 by Masinter
204, s5300
DD -- Issue: DEFMACRO-LAMBDA-LIST
10-Apr-89, V.4 Masinter (forgot an amendment)
209
DD -- Issue: DEFPACKAGE
Version 7, 2-Nov-88, JonL
753, chapter6, s6100, PACKAGES
DD -- Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
8-Jan-89, Version 3, Masinter
Allow &KEY keyword arguments in constructor forms of DEFSTRUCTs and
...
212
DD -- Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Revision 1 by Skona Brittain 05/13/88
212
DD -- Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
V3, 7 Dec 1988, Masinter
Clarify print function inheritance.
212
DD -- Issue: DEFSTRUCT-REDEFINITION
Version 3 by Masinter 6-Feb-89 as per Jan 89 X3J13 amendment
212
**need new version of this one
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-JAN-89
DD -- Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Edit history: Revision 1 by Skona Brittain 05/13/88
DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER.TXT;1 -- allow
a call to defstruct to have no slot-descriptions.
f212
DD -- Issue: DEFVAR-DOCUMENTATION
23-Nov-87, Version 2 by Masinter
DEFVAR-DOCUMENTATION -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DEFVAR-DOCUMENTATION.TXT;1 -- documentation part
of these forms isn't evaluated.
f215, f210, f206
DD -- Issue: DEFVAR-INIT-TIME
29-Mar-87, Version 2 by Masinter
DEFVAR-INIT-TIME -- passed June 87 meeting
clarifies time at which defvar initialization occurs.
f215
DD -- Issue: DEFVAR-INITIALIZATION
Version 4 by Masinter 5-Jun-87
DEFVAR-INITIALIZATION -- passed June 87 meeting
clarifies what happens if an init value isn't provided.
f215
DD -- Issue: DESCRIBE-INTERACTIVE:NO
15-Nov-88, Version 4 by Pierson, two-proposal version
Clarify DESCRIBE's interactive behavior.
911 (generic function describe), 223 (normal function describe)
DD -- Issue: DESCRIBE-UNDERSPECIFIED
Version 2, 9-Apr-89, Masinter (as per Mar 89 X3J13)
911 (generic function describe deleted), 223 (normal function describe
augmented with changes from DESCRIBE-INTERACTIVE:NO and this issue), 754,
CLOS, Chapter6
DD -- Issue: DESTRUCTURING-BIND
29-Mar-89, Version 3, by Moon, amended based on poll
755, Chapter6, MACROS, is this affected by DEFMACRO-LAMBDA-LIST and
DOTTED-MACRO-FORMS?
DD -- Issue: DISASSEMBLE-SIDE-EFFECT
Version 3 by Pierson 1/21/88
DISASSEMBLE-SIDE-EFFECT -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DISASSEMBLE-SIDE-EFFECT.TXT;1 -- disassemble should
never install the newly-compiled function.
f228
DD -- Issue: DO-SYMBOLS-DUPLICATES
Version 3 by Masinter 23-Nov-87
DO-SYMBOLS-DUPLICATES -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DO-SYMBOLS-DUPLICATES.TXT;1 -- the body may be
executed more than once for some symbols.
f232
DD -- Issue: DOTTED-MACRO-FORMS
15-Nov-88, Version 3 by Pitman (revive allow, flush disallow)
Define that it is permissible for a macro form (or subform)
to be a dotted list when "&REST var" or ". var" is used to match
it.
209, does this effect DESTRUCTURING-BIND?
DD -- Issue: DRIBBLE-TECHNIQUE
14-Feb-88, Version 2 by Masinter
DRIBBLE-TECHNIQUE -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]DRIBBLE-TECHNIQUE.TXT;1 -- clarify that dribble
isn't portable.
f239
DD -- Issue: DYNAMIC-EXTENT
05-Apr-89, Version 4 by Pitman and Steele (changes per X3J13)
202
DD -- Issue: EQUAL-STRUCTURE
15-Mar-89, Version 7 by Masinter (amended as per vote at Jan 89 X3J13)
250, 249
DD -- Issue: EVAL-OTHER
8-Jun-88, Version 2 by Masinter (correct typo, add to discussion)
s4100
DD -- Issue: EXIT-EXTENT:MINIMAL
Version 7, 4-Apr-89, Moon, amend per X3J13 Mar-89, and make
rationale and examples consistent with that
Glossary, 317, 578, 680, (no changes to catch, block, or tagbody),
examples added to unwind-protect (697)
DD -- Issue: EXPT-RATIO
Version 3, 31-Oct-88, Masinter (fix typo)
Clarify that (sqrt (expt x 3)) is not equivalent to (expt x 3/2)
and that page 211 rules.
f*.exp
DD -- Issue: FIXNUM-NON-PORTABLE
Version 6, 17-Mar-89, Masinter (incorporate amendments correctly)
s2200, 040, 440
DD -- Issue: FLET-DECLARATIONS
Version 2, Moon, 2 Feb 1988 (edits suggested by Masinter)
FLET-DECLARATIONS -- passed March 88 meeting
allow declarations in flet, labels, and macrolet.
f283
DD -- Issue: FLET-IMPLICIT-BLOCK
Version 6 by Masinter 5-Jun-87
FLET-IMPLICIT-BLOCK -- passed June 87 meeting
DUA1:[CHAPMAN.FROM-OFFICE]IMPLICIT-BLOCKS.TXT;1 -- put implicit blocks around
flet, labels... (this is the flet-implicit-block proposal)
f283, f209, f211, f208, f213
DD -- Issue: FORMAT-ATSIGN-COLON
Version 4 by Masinter 5-Jun-87
FORMAT-ATSIGN-COLON -- passed June 87 meeting
clarifies the @: relationship.
f293
DD -- Issue: FORMAT-COLON-UPARROW-SCOPE
version 3: Masinter, 5 February 1988
FORMAT-COLON-UPARROW-SCOPE -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]FORMAT-COLON-UPARROW-SCOPE.TXT;1 -- iteration
termination within format.
f293
DD -- Issue: FORMAT-COMMA-INTERVAL
Version 2, Masinter, 15-Jun-87
FORMAT-COMMA-INTERVAL -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]FORMAT-COMMA-INTERVAL.TXT;1 -- add another argument
to the format directives for printing numbers in certain radices that
says how many digits are printed between commas when printing the number
out: 100,000,001 could be 10,0000,0001?
f293
DD -- Issue: FORMAT-E-EXPONENT-SIGN
V2 Masinter, 2-Oct-88 (change issue name)
Specify that ~E always prints a plus or minus sign in front of the
exponent.
293
DD -- Issue: FORMAT-OP-C
11-Jun-87, Version 5 release to X3J13
FORMAT-OP-C -- passed June 87 meeting
change behavior of ~C.
293
DD -- Issue: FORMAT-PRETTY-PRINT
Version 7 by Pierson 11/15/88 "does" => "does not"
Specify that FORMAT does not rebind any of the printer control
variables (*PRINT-...) except as follows:
293, 520, 517, 524 (added example)
DD -- Issue: FUNCTION-CALL-EVALUATION-ORDER
(passed October 1989)
Version 1 by Clinger (22 March 1988)
s4100
***check constantly***
DD -- Issue: FUNCTION-COMPOSITION
10-Feb-89, Version 5 (as amended by X3J13 Jan 89)
756, chapter6, sequences (constantly not added, still checking)
DD -- Issue: FUNCTION-DEFINITION
10-Feb-89, Version 3, as amended Jan 89 X3J13
757, chapter6, miscellaneous-features
DD -- Issue: FUNCTION-NAME:LARGE (amended, I amended myself, maybe new
copy will come out)
Version 1, 23-Jan-89, by Moon
(based on discussion at X3J13 meeting)
s6100, macros2, macros2a, 758, 599, 263, (291), 413, 299, 908, 913, 907,
910, 919, 912, 214, 176, 228, 202, 682, 241
**need help on one point in this issue**
DD -- Issue: FUNCTION-TYPE
4-Sep-88, Version 12 by Masinter
FUNCTION-TYPE -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]FUNCTION-TYPE.TXT;1 -- clarify what the term
`function' means. Clarify the role of the function type specifier, specify
what the type function is disjoint from.
s2400, s2200, s2300, s4100, f414, f034, f298, f300, f689, f299, f263, f664,
f599, f174, f393
DD -- Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
#3, 7-Dec-88, Masinter
Specify that a declaration of the form
(ftype (function (arg0-type arg1-type ...) val-type) f))
implies that any call of the form (f arg0 arg1 ...) within the scope of
the declaration can be treated as if it were
s2200
DD -- Issue: FUNCTION-TYPE-KEY-NAME
Version 3, 13-Feb-88 Masinter
FUNCTION-TYPE-KEY-NAME -- passed June 88 meeting
specifies how the &key arguments are supplied to the type function.
s2400
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88 Masinter (add to discussion)
Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.
s2200
DD -- Issue: GENSYM-NAME-STICKINESS
20-Mar-89, Version 3 by Pitman (make it a variable)
302, sa400, 759, chapter6, symbols
DD -- Issue: GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89, as amended Jan 89 X3J13
(306), 595, (309), 597
DD -- Issue: GET-SETF-METHOD-ENVIRONMENT
Version 5 13-Jul-87, by Masinter
GET-SETF-METHOD-ENVIRONMENT -- passed June 87 meeting
DUA1:[CHAPMAN.FROM-OFFICE]GET-SETF-METHOD-ENVIRONMENT.TXT;1 -- add environment
argument to get-setf-method.
f313, f208, f207
DD -- Issue: HASH-TABLE-ACCESS
05-Apr-89, version 3 by Pitman (changes per x3J13)
760, 761, 762, 763, chapter6, hash-tables
DD -- Issue: HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Masinter (add comment to discussion)
Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR
to the language as follows:
764, 765, chapter7, hash-tables, packages
DD -- Issue: HASH-TABLE-TESTS
8-Dec-88 Version 2 by Masinter
With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we
can expect EQUALP to be a true equivalence function, and thus a suitable
401, s6100
DD -- Issue: IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Masinter (1st => 3rd person)
Redefine the branch cut for two-argument ATAN, covering
the cases where there is or is not a minus zero, and then redefine *all*
other functions that have branch cuts in terms of two-argument ATAN.
367, 623, 503, (059), 053, 260, (054), 615, 023
DD -- Issue: IMPORT-SETF-SYMBOL-PACKAGE
Version 5 to X3J13
IMPORT-SETF-SYMBOL-PACKAGE -- passed June 87 meeting
clarifies action of import on home package.
f325
DD -- Issue: IN-SYNTAX
Version 3, 9-Apr-89, Masinter
(Include discussion from Version 1)
177, 364
DD -- Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
8-Nov-87, Version 8 by Moon
KEYWORD-ARGUMENT-NAME-PACKAGE -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]KEYWORD-ARGUMENT-NAME-PACKAGE.TXT;1 -- allow keywords
to be in other packages besides the keyword package.
s4100, there are other UNMARKED changes sprinkled throughout the document
that seek to avoid confusion between keyword and keyword name.
DD -- Issue: LAST-N
12-Mar-88, Version 2 by Pitman
LAST-N -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]LAST-N.TXT;1 -- add a new argument to last that
specifies the number of elements of the list to return.
f342
DD -- Issue: LCM-NO-ARGUMENTS
Edit history: Version 1, Guy Steele 10/17/88
Define (lcm) to return the integer 1.
343
DD -- Issue: LISP-PACKAGE-NAME
9-Apr-89, version 2 by Masinter, incorporate
changes per Mar 89 amendments.
s2200, 326, 403, 484, 753
modified examples in the following files: 279, 280, 303, 325, 488,
490, 829, 335, 385, 485, 603, 690, 691, 696
DD -- Issue: LISP-SYMBOL-REDEFINITION
Masinter, Version 6, 9-Apr-89, make Mar 89 X3j13 amendments
s2200, 214, 209, 212, 907, 213, 527, 682, 202, 356, 283
***may need more work on this one, notes in issue***
DD -- Issue: LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, by Moon, fix referenced proposal name
366, eval-when-non-top-level
DD -- Issue: LOOP-AND-DISCREPANCY
Edit history: Version 1, 15-Mar-88 by Steele
385
DD -- Issue: MACRO-FUNCTION-ENVIRONMENT
Version 2, Masinter, 8-Jun-88, (as per cleanup discussion)
MACRO-FUNCTION-ENVIRONMENT -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]MACRO-FUNCTION-ENVIRONMENT.TXT;1 -- add an
environment argument to macro-function.
f390, f209
*** need v3*** Issue: MAKE-PACKAGE-USE-DEFAULT
Masinter, 8-Oct-88 (version 2)
Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if
adopted, and IN-PACKAGE, if IN-PACKAGE-FUNCTIONALITY is not
adopted) so that the default for the :USE keyword is
DD -- Issue: MAPPING-DESTRUCTIVE-INTERACTION
09-Jun-88, Version 2 by Pitman
Clarify that it in general is an error (the effect is not defined
but in general no error will be signalled) for code executed during a
s6100, 027, 056, 196, (216), 568, (230), (217), 232, 234, 254,
259, 275, 336, 385, 414, 419, 424, 427, 431, (458), 459), 594,
596, 652, 655, 658, 692, 507, 544, 564, 590, 621, 654, 684, 764, 765,
710, 713
DD -- Issue: NTH-VALUE
17-Mar-89, Version 5, Masinter (as amended)
766, chapter7, control-structure
DD -- Issue: PACKAGE-CLUTTER
17-Mar-89, Version 7 by Masinter (as amended Jan 89 X3J13)
s2200
DD -- Issue: PACKAGE-DELETION
21-Nov-88, Version 5 by Masinter
Introduce the function DELETE-PACKAGE, described as follows:
767, chapter6, packages
DD -- Issue: PACKAGE-FUNCTION-CONSISTENCY
17-Mar-89, Version 4, by Moon, correct amended wording
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
403, 326, 279, 767, 335, 691, 261, 699, 696, 753, 690, 325, 603, 602,
485, 486, 488, 489, 232
***still a question about unuse-package and use-package
DD -- Issue: PATHNAME-UNSPECIFIC-COMPONENT
17-Mar-89, Version 2 by Masinter (as amended)
Permit :UNSPECIFIC as a value of all
fields of a pathname for file systems in which it makes sense.
s2200, 404, 428, 497, 700
DD -- Issue: PATHNAME-STREAM
Version 6 by Masinter 14-Nov-87
PATHNAME-STREAM -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]PATHNAME-STREAM.TXT;1 -- clarify that only a stream
associated with a file can be used in pathname functions.
macros2, f685, f493, f428, f497, f451, f494,
f481, f711, f573, f218, s6100 (by changing macros2.tex)
changed conditions section in all the above files.
what is OPEN-STRING-STREAM???
DD -- Issue: PATHNAME-SYMBOL
Version 5 by Masinter 5-Feb-88, fix minor typo
PATHNAME-SYMBOL -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]PATHNAME-SYMBOL.TXT;1 -- disallow symbols for
lots of fucntions where pathnames are required (e.g. (load 'foo) -> (load
"foo)
macros2, f494 (examples, unmarked), f493, f451
** this one may come up again?
Issue: PEEK-CHAR-READ-CHAR-ECHO
8-Oct-88, Version 3 by Pitman & Masinter
Ammend the description of READ-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), the character
will be echoed on the stream the first time those characters are seen.
DD -- Issue: PRINC-CHARACTER
29-Apr-87, Version 2 by Pitman (removed FORMAT-OP-C)
PRINC-CHARACTER -- passed June 87 meeting
clarify what princ on a character means.
f714
DD -- Issue: PRINT-CIRCLE-STRUCTURE
Version 4, Masinter, 17-Mar-89 (as amended)
When *print-circle* is T, a user defined print-function or method on
PRINT-OBJECT can print
objects to the supplied stream using WRITE, PRIN1, PRINC, or FORMAT
519, 212, 929,
DD -- Issue: PUSH-EVALUATION-ORDER
Version 5, 25-Nov-87, Larry Masinter
PUSH-EVALUATION-ORDER -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]PUSH-EVALUATION-ORDER.TXT;1 -- specified the
evaluation order of generalized references within macros.
f537, s5400, f315, f566, f327, f604, f599, f506, f344, f207, f807, f810,
f813, f803
DD -- Issue: RANGE-OF-COUNT-KEYWORD
09-Oct-88, Version 3 by Pitman
Clarify that for the functions ...
568, 658
DD -- Issue: RANGE-OF-START-AND-END-PARAMETERS
Edit history: 14-Sep-88, Version 1 by Pitman
Clarify that for functions permitting a parameter named START, START1,
or START2 which delimits the beginning point in a sequence to be
considered for some operation, that paremeter must be a non-negative
integer. If the argument is optional or key (as is the case for all
196, 273, 275, 407, 431, 492, 493, 507, 557, 564, 568, 569, 575, 590,
644, 648, 653, 658, 718
DD -- Issue: REAL-NUMBER-TYPE
05-APR-89, Version 4 by Pitman (changes per X3J13)
s2200, 768, chapter7, predicates
DD -- Issue: REDUCE-ARGUMENT-EXTRACTION
Version 3 by Masinter 13-Feb-88
REDUCE-ARGUMENT-EXTRACTION -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]REDUCE-ARGUMENT-EXTRACTION.TXT;1 -- add :key to
reduce and others.
f564, f212
DD -- Issue: REMF-DESTRUCTION-UNSPECIFIED
05-Apr-89, Version 7 by Pitman (typos corrected per X3J13)
315, 566, 572, (461), 581, (216), 568, 569, 460, (479), 692,
453, 336, 596, 658
DD -- Issue: REQUIRE-PATHNAME-DEFAULTS
Version 6 by Pierson 12/9/88, remove *MODULES* as well
Remove PROVIDE, REQUIRE, and *MODULES* from the Common Lisp standard.
sa300, 534, 433, s6100, eventually chapter6, chapter7, packages
DD -- Issue: REST-LIST-ALLOCATION
12-Dec-88, Version 3 by Clinger (delete bogus examples)
Specify that the value of an &REST parameter is permitted, but not required,
to share (top-level) structure with the last argument to APPLY.
s4100
DD -- Issue: RETURN-VALUES-UNSPECIFIED
9-Dec-88, Version 6 by Masinter
Clarify that the return values for the listed constructs are as follows:
171, 326, 574, 682, 335, 484, 485, 603, 690, 691, 696, 218, 329, 598,
366, 190, 561, 598
DD -- Issue: ROOM-DEFAULT-ARGUMENT
Edit history: 12-Sep-88, Version 1 by Pitman
Specify that passing an argument of :DEFAULT is equivalent to passing
no argument to ROOM.
582
** still an outstanding question @ rotatef... on this one. (JonL)
DD -- Issue: SETF-SUB-METHODS
Version 5: Masinter (respond to comments)
This proposal specifies more explicilty the behavior of SETF in the case
of access forms whose sub-forms are permitted to be generalized variable
references [and which thus need to call GET-SETF-METHOD during setf macro
expansion].
599
DD -- Issue: SHADOW-ALREADY-PRESENT
Version 4 Masinter 10-Nov-87
SHADOW-ALREADY-PRESENT -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]SHADOW-ALREADY-PRESENT.TT;1 -- change shadow
to add the symbol even if it is already present.
f602
DD -- Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 by Masinter 14-Nov-87
SHARPSIGN-PLUS-MINUS-PACKAGE -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]SHARPSIGN-PLUS-MINUS-PACKAGE.TXT;1 -- the default
package while reading features is the keyword package.
s3100, f265
DD -- Issue: SPECIAL-TYPE-SHADOWING
Edit history: Version 1, 04-Nov-88 by David Gray
Clarify that if there is a local type declaration for a special
variable, and there is also a global type proclamation for that same
variable, then the value of the variable within the scope of the local
declaration must be a member of the intersection of the two declared
types.
202
DD -- Issue: STANDARD-INPUT-INITIAL-BINDING
Version 8 by Pierson 7/ 8/88, yet more clean up
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as
defined in CLtL. This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.
626, 627, 252, 683, 539, 200, 676
Issue: STEP-ENVIRONMENT
***need v4***
1. Clarify that STEP and TIME evaluate the form in the current environment.
Issue: STREAM-ACCESS
30-Nov-88, version 2 by Masinter
First, add a function to determine whether a stream is "OPEN":
769, 770, 771, 772, 773, 774, 775, 776, chapter6, chapter7, streams,
s2200, 369, 398, 400, 481, 407, 710, 411, 711, 408, 713
DD -- Issue: SUBSEQ-OUT-OF-BOUNDS
29-Mar-88, Version 2 by Steele, in response to Moon's comments
SUBSEQ-OUT-OF-BOUNDS -- passed June 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]SUBSEQ-OUT-OF-BOUNDS.TXT;1 -- specify what happens
when :start and :end arguments are out of bounds.
f653, f196, f273, f275, f431, f492, f493, f507, f557, f564, 568, f216,
f569, f575, 590, f644, f648, f658, f710, f718
** need new version
Issue: SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
DD -- Issue: SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Masinter
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS. Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
202, 939
DD -- Issue: SYMBOL-MACROLET-SEMANTICS
14-Mar-89, Version 6 by Steele
939, 391, 600, 448
DD -- Issue: TAILP-NIL
9-Dec-88, Version 5 by Masinter (clarify EQL)
Strike any text in the definition of TAILP which suggests that a
sublist must be a cons.
672
DD -- Issue: UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2 by Masinter 2-Dec-88
Rewrite the specification so that it is clear that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
694, 502, 554
** need new version
Issue: VARIABLE-LIST-ASYMMETRY
08-Oct-88, Version 3 by Pitman
Allow all the variations in all of the forms;
i.e. add the prohibited cases mentioned above.
DD -- Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (passed June 88?)
Version 5, 7-Jun-88 Masinter (more nits)
713
**************************************************************************
compiler issues follow: these will be included after the completion of
the compiler section (4.2) if they have not already been included.
DD -- Issue: ALLOW-LOCAL-INLINE
30 Dec. 88 V4 by Sandra Loosemore -- suggestions from Pitman
Clarifies use of INLINE proclamation.
s4200
DD -- Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
V8, 31 Dec 1988 Sandra Loosemore
Clarify what the effect of COMPILE-FILE is.
s4200
Issue: COMPILER-DIAGNOSTICS
V10, 22 Mar 1989, Sandra Loosemore (error terminology)
Issue: COMPILER-LET-CONFUSION
V8, 23 Mar 1989, Sandra Loosemore (fix another bug, add
to discussion)
Issue: COMPILER-VERBOSITY
V6, 26 Jan 1989, Sandra Loosemore (remove USE-CONDITIONS)
Issue: CONSTANT-CIRCULAR-COMPILATION:YES
V8, 18 Mar 1989, Sandra Loosemore (changes per Moon, Masinter)
Issue: CONSTANT-COLLAPSING
V6, 22 Mar 1989, Sandra Loosemore (comments from Moon)
Issue: CONSTANT-COMPILABLE-TYPES
03/22/89, V9 by Loosemore (restructure)
DD -- Issue: CONSTANT-MODIFICATION
V2, 12 Dec 1988, Sandra Loosemore
Disallow modification of constants inside QUOTE.
039, 062, 137, 243, 652, 662, 599
Issue: DEFCONSTANT-SPECIAL
V3, 30 Dec 1988, Sandra Loosemore
Issue: DEFINING-MACROS-NON-TOP-LEVEL 315
22-Mar-89, V9 by Sandra Loosemore (add MACROLET stuff)
Issue: EVAL-WHEN-NON-TOP-LEVEL
22-Mar-89, Version 7 by Loosemore (order of processing)
Issue: LOAD-OBJECTS
Version 4, 4-Apr-89, by Pitman (changes per X3J13 Mar 89;
MAKE-LOAD-FORM-USING-SLOTS => MAKE-LOAD-FORM-SAVING-SLOTS)
Issue: LOAD-TIME-EVAL:R**3
11-Mar-89, Version 11 by Loosemore
Issue: MACRO-ENVIRONMENT-EXTENT:DYNAMIC
V3, 13 Mar 1989, Sandra Loosemore (last-minute discussion)
Issue: QUOTE-SEMANTICS:NO-COPYING
V3, 22 Mar 1989, Sandra Loosemore (suggestions from Moon)
Issue: SHARP-COMMA-CONFUSION
V2, 30 Dec 1988, Sandra Loosemore (comments from Pitman)
Remove the #, read macro from the language.
Issue: WITH-COMPILATION-UNIT:NEW-MACRO
13-Mar-89, Version 3 by Loosemore (update discussion)
****************************************************************************
editorial issues: they will either be part of chapter 1, part of the
error terminology, or a policy.
Issue: DEPRECATION-POSITION
9-JAN-89, Version 3 by Chapman
"policy"
Issue: SUBSETTING-POSITION
10-MAR-89, Version 5 by Chapman (added discussion)
"policy"
Issue: EXTENSIONS-POSITION:DOCUMENTATION
10-MAR-89, Version 7 by Chapman (added discussion)
1.7
Issue: UNSOLICITED-MESSAGES
6-APR-89, Version 6 by Chapman (added amendment from 3/89 mtg)
1.7
Issue: ERROR-TERMINOLOGY
14-APR-89, Version 9 by Chapman (added SAFE-CODE clarification
"error terms"
Issue: MACRO-AS-FUNCTION:DISALLOW
6-FEB-89, Version 2 by Chapman
1.7
***take this one out***DD -- APPEND-DOTTED -- passed March 88 meeting
DUA1:[CHAPMAN.FROM-OFFICE]APPEND-DOTTED.TXT;1 -- clarify what happens
when non-last element is a dotted list.
f033,f453
*****************************************************************************
Issues that will probably come up and pass in some form in June:
*****************************************************************************
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
Issue: DYNAMIC-EXTENT-FUNCTION
Edit history: 04-Apr-89, Version 1 by Loosemore
Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
Edit history: 06-Mar-89, Version 1 by Pitman
Issue: HASH-TABLE-SIZE
Edit history: Version 1, 20-Mar-89, by Moon
Issue: LOAD-TRUENAME
11-Apr-89, Version 4 by Pitman (merge Moon's v3 comments)
Issue: PATHNAME-COMPONENT-CASE
22-Mar-89, Version 2 by Moon, update and rewrite
Issue: PATHNAME-COMPONENT-VALUE
Edit history: Version 1, 20-Mar-89, by Moon
Issue: PATHNAME-SUBDIRECTORY-LIST
23-Mar-89, Version 4 by Pitman ([hopefully] just fix typos)
Issue: PATHNAME-SYNTAX-ERROR-TIME
Edit history: 07-Jul-88, Version 1 by Pitman
Issue: PATHNAME-WILD
06-Oct-88, Version 2 by Pitman
Issue: PRETTY-PRINT-INTERFACE
Version 4, 22-Mar-89 by Waters
Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
Edit history: 26-Jan-89, Version 1 by Pitman
Issue: READ-CASE-SENSITIVITY
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Issue: CLOS-MACRO-COMPILATION
V3, 21 Mar 1989, Sandra Loosemore (fix error language)
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
V5, 22 Mar 1989, Sandra Loosemore (fix error language)
Issue: COMPILE-FILE-SYMBOL-HANDLING
V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
Issue: COMPILED-FUNCTION-REQUIREMENTS
V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)
Issue: CONSTANT-FUNCTION-COMPILATION
Edit History: V1, 22 Mar 1989, Sandra Loosemore (split from issue
CONSTANT-COMPILABLE-TYPES)
Issue: DEFCONSTANT-NOT-WIRED
13 Mar 1989, V6 by Sandra Loosemore (start over)
Issue: MACRO-CACHING
11-Mar-89, Version 2 by Loosemore (add discussion)
Issue: PROCLAIM-ETC-IN-COMPILE-FILE
13 Mar 89, V4 by Sandra Loosemore (discussion)
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Version 6, 23-Mar-89, Sandra Loosemore (more revisions)
Issue: CONFORMANCE-POSITION
Issue: EXTRA-RETURN-VALUES
∂03-May-89 0428 Quinquevirate-mailer file name/number mapping
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 89 04:28:05 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA17913; Wed, 3 May 89 04:29:05 PDT
Message-Id: <8905031129.AA17913@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA17913; Wed, 3 May 89 04:29:05 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 May 89 07:08
To: quinquevirate@sail.stanford.edu
Subject: file name/number mapping
Where there are names duplicated (NOT numbers, hopefully), the
file with the higher number has superceded the file with the lower
number (for example BREAK-ON-WARNINGS).
F001.STAR
F002.STARVAR
F003.STARSTAR
F004.STARSTARSTAR
F005.PLUS
F006.PLUSVAR
F007.PLUSPLUS
F008.PLUSPLUSPLUS
F009.MINUS
F010.MINUSVAR
F011.SLASH
F012.SLASHVAR
F013.SLASHSLASH
F014.SLASHSLASHSLASH
F015.SLASHEQSIGN
F016.1PLUS
F017.1MINUS
F018.LESSTHAN
F019.LESSTHANEQSIGN
F020.EQSIGN
F021.GTRTHAN
F022.GTRTHANEQSIGN
F023.ABS
F024.ACONS
F025.ACOSH
F026.ACOS
F027.ADJOIN
F028.ADJUST-ARRAY
F029.ADJUSTABLE-ARRAY-P
F030.ALPHA-CHAR-P
F031.ALPHANUMERICP
F032.AND
F033.APPEND
F034.APPLY
F035.APPLYHOOK
F036.APPLYHOOKVAR
F037.APROPOS
F038.APROPOS-LIST
F039.AREF
F040.ARRAY-DIMENSION-LIMIT
F041.ARRAY-DIMENSION
F042.ARRAY-DIMENSIONS
F043.ARRAY-ELEMENT-TYPE
F044.ARRAY-HAS-FILL-POINTER-P
F045.ARRAY-IN-BOUNDS-P
F046.ARRAY-RANK
F047.ARRAY-RANK-LIMIT
F048.ARRAY-ROW-MAJOR-INDEX
F049.ARRAY-TOTAL-SIZE
F050.ARRAY-TOTAL-SIZE-LIMIT
F051.ARRAYP
F052.ASH
F053.ASIN
F054.ASINH
F055.ASSERT
F056.ASSOC
F057.ASSOC-IF
F058.ASSOC-IF-NOT
F059.ATAN
F060.ATANH
F061.ATOM
F062.BIT
F063.BIT-AND
F064.BIT-ANDC1
F065.BIT-ANDC2
F066.BIT-EQV
F067.BIT-IOR
F068.BIT-NAND
F069.BIT-NOR
F070.BIT-NOT
F071.BIT-ORC1
F072.BIT-ORC2
F073.BIT-VECTOR-P
F074.BIT-XOR
F075.BLOCK
F076.BOOLE
F077.BOOLE-1
F078.BOOLE-2
F079.BOOLE-AND
F080.BOOLE-ANDC1
F081.BOOLE-ANDC2
F082.BOOLE-C1
F083.BOOLE-C2
F084.BOOLE-CLR
F085.BOOLE-EQV
F086.BOOLE-IOR
F087.BOOLE-NAND
F088.BOOLE-NOR
F089.BOOLE-ORC1
F090.BOOLE-ORC2
F091.BOOLE-SET
F092.BOOLE-XOR
F093.BOTH-CASE-P
F094.BOUNDP
F095.BREAK
F096.BREAK-ON-WARNINGS
F097.BUTLAST
F098.BYTE
F099.BYTE-POSITION
F100.BYTE-SIZE
F101.CAAAAR
F102.CAAADR
F103.CAAAR
F104.CAADAR
F105.CAADDR
F106.CAADR
F107.CAAR
F108.CADAAR
F109.CADADR
F110.CADAR
F111.CADDAR
F112.CADDDR
F113.CADDR
F114.CADR
F115.CALL-ARGUMENTS-LIMIT
F116.CAR
F117.CASE
F118.CATCH
F119.CCASE
F120.CDAAAR
F121.CDAADR
F122.CDAAR
F123.CDADAR
F124.CDADDR
F125.CDADR
F126.CDAR
F127.CDDAAR
F128.CDDADR
F129.CDDAR
F130.CDDDAR
F131.CDDDDR
F132.CDDDR
F133.CDDR
F134.CDR
F135.CEILING
F136.CERROR
F137.CHAR
F138.CHAR-BIT
F139.CHAR-BITS-LIMIT
F140.CHAR-BITS
F141.CHAR-CODE
F142.CHAR-CODE-LIMIT
F143.CHAR-CONTROL-BIT
F144.CHAR-DOWNCASE
F145.CHAR-EQUAL
F146.CHAR-FONT
F147.CHAR-FONT-LIMIT
F148.CHAR-GREATERP
F149.CHAR-HYPER-BIT
F150.CHAR-INT
F151.CHAR-LESSP
F152.CHAR-META-BIT
F153.CHAR-NAME
F154.CHAR-NOT-EQUAL
F155.CHAR-NOT-GREATERP
F156.CHAR-NOT-LESSP
F157.CHAR-SUPER-BIT
F158.CHAR-UPCASE
F159.CHARSLASHEQSIGN
F160.CHARLESSTHAN
F161.CHARLESSTHANEQSIGN
F162.CHAREQSIGN
F163.CHARGTRTHAN
F164.CHARGTRTHANEQSIGN
F165.CHARACTERP
F166.CHARACTER
F167.CHECK-TYPE
F168.CIS
F169.CLEAR-INPUT
F170.CLEAR-OUTPUT
F171.CLOSE
F172.CLRHASH
F173.CODE-CHAR
F174.COERCE
F175.COMMONP
F176.COMPILE
F177.COMPILE-FILE
F178.COMPILED-FUNCTION-P
F179.COMPILER-LET
F180.COMPLEXP
F181.COMPLEX
F182.CONCATENATE
F183.COND
F184.CONJUGATE
F185.CONS
F186.CONSP
F187.CONSTANTP
F188.COPY-ALIST
F189.COPY-LIST
F190.COPY-READTABLE
F191.COPY-SEQ
F192.COPY-SYMBOL
F193.COPY-TREE
F194.COS
F195.COSH
F196.COUNT
F197.COUNT-IF
F198.COUNT-IF-NOT
F199.CTYPECASE
F200.DEBUG-IO
F201.DECF
F202.DECLARE
F203.DECODE-FLOAT
F204.DECODE-UNIVERSAL-TIME
F205.DEFAULT-PATHNAME-DEFAULTS
F206.DEFCONSTANT
F207.DEFINE-MODIFY-MACRO
F208.DEFINE-SETF-METHOD
F209.DEFMACRO
F210.DEFPARAMETER
F211.DEFSETF
F212.DEFSTRUCT
F213.DEFTYPE
F214.DEFUN
F215.DEFVAR
F216.DELETE
F217.DELETE-DUPLICATES
F218.DELETE-FILE
F219.DELETE-IF
F220.DELETE-IF-NOT
F221.DENOMINATOR
F222.DEPOSIT-FIELD
F223.DESCRIBE
F224.DIGIT-CHAR
F225.DIGIT-CHAR-P
F226.DIRECTORY
F227.DIRECTORY-NAMESTRING
F228.DISASSEMBLE
F229.DO-DOSTAR
F230.DO-ALL-SYMBOLS
F231.DO-EXTERNAL-SYMBOLS
F232.DO-SYMBOLS
F233.DOCUMENTATION
F234.DOLIST
F235.DOTIMES
F236.DOUBLE-FLOAT-EPSILON
F237.DOUBLE-FLOAT-NEGATIVE-EPSILON
F238.DPB
F239.DRIBBLE
F240.ECASE
F241.ED
F242.EIGHTH
F243.ELT
F244.ENCODE-UNIVERSAL-TIME
F245.ENDP
F246.ENOUGH-NAMESTRING
F247.EQ
F248.EQL
F249.EQUALP
F250.EQUAL
F251.ERROR
F252.ERROR-OUTPUT
F253.ETYPECASE
F254.EVAL
F255.EVAL-WHEN
F256.EVALHOOKVAR
F257.EVALHOOK
F258.EVENP
F259.EVERY
F260.EXP
F261.EXPORT
F262.EXPT
F263.FBOUNDP
F264.FCEILING
F265.FEATURES
F266.FFLOOR
F267.FIFTH
F268.FILE-AUTHOR
F269.FILE-LENGTH
F270.FILE-NAMESTRING
F271.FILE-POSITION
F272.FILE-WRITE-DATE
F273.FILL
F274.FILL-POINTER
F275.FIND
F276.FIND-ALL-SYMBOLS
F277.FIND-IF
F278.FIND-IF-NOT
F279.FIND-PACKAGE
F280.FIND-SYMBOL
F281.FINISH-OUTPUT
F282.FIRST
F283.FLET
F284.FLOAT
F285.FLOAT-DIGITS
F286.FLOAT-PRECISION
F287.FLOAT-RADIX
F288.FLOAT-SIGN
F289.FLOATP
F290.FLOOR
F291.FMAKUNBOUND
F292.FORCE-OUTPUT
F293.FORMAT
F294.FOURTH
F295.FRESH-LINE
F296.FROUND
F297.FTRUNCATE
F298.FUNCALL
F299.FUNCTION
F300.FUNCTIONP
F301.GCD
F302.GENSYM
F303.GENTEMP
F304.GET
F305.GET-DECODED-TIME
F306.GET-DISPATCH-MACRO-CHARACTER
F307.GET-INTERNAL-REAL-TIME
F308.GET-INTERNAL-RUN-TIME
F309.GET-MACRO-CHARACTER
F310.GET-OUTPUT-STREAM-STRING
F311.GET-PROPERTIES
F312.GET-SETF-METHOD-MULTIPLE-VALUE
F313.GET-SETF-METHOD
F314.GET-UNIVERSAL-TIME
F315.GETF
F316.GETHASH
F317.GO
F318.GRAPHIC-CHAR-P
F319.HASH-TABLE-COUNT
F320.HASH-TABLE-P
F321.HOST-NAMESTRING
F322.IDENTITY
F323.IF
F324.IMAGPART
F325.IMPORT
F326.IN-PACKAGE
F327.INCF
F328.INPUT-STREAM-P
F329.INSPECT
F330.INT-CHAR
F331.INTEGER-DECODE-FLOAT
F332.INTEGER-LENGTH
F333.INTEGERP
F334.INTERNAL-TIME-UNITS-PER-SECOND
F335.INTERN
F336.INTERSECTION
F337.ISQRT
F338.KEYWORDP
F339.LABELS
F340.LAMBDA-LIST-KEYWORDS
F341.LAMBDA-PARAMETERS-LIMIT
F342.LAST
F343.LCM
F344.LDB
F345.LDB-TEST
F346.LDIFF
F347.LEAST-NEGATIVE-DOUBLE-FLOAT
F348.LEAST-NEGATIVE-LONG-FLOAT
F349.LEAST-NEGATIVE-SHORT-FLOAT
F350.LEAST-NEGATIVE-SINGLE-FLOAT
F351.LEAST-POSITIVE-DOUBLE-FLOAT
F352.LEAST-POSITIVE-LONG-FLOAT
F353.LEAST-POSITIVE-SHORT-FLOAT
F354.LEAST-POSITIVE-SINGLE-FLOAT
F355.LENGTH
F356.LET-LETSTAR
F357.LISP-IMPLEMENTATION-TYPE
F358.LISP-IMPLEMENTATION-VERSION
F359.LIST-LISTSTAR
F360.LIST-ALL-PACKAGES
F361.LIST-LENGTH
F362.LISTEN
F363.LISTP
F364.LOAD
F365.LOAD-VERBOSE
F366.LOCALLY
F367.LOG
F368.LOGANDC1
F369.LOGANDC2
F370.LOGAND
F371.LOGBITP
F372.LOGCOUNT
F373.LOGEQV
F374.LOGIOR
F375.LOGNAND
F376.LOGNOR
F377.LOGNOT
F378.LOGORC1
F379.LOGORC2
F380.LOGTEST
F381.LOGXOR
F382.LONG-FLOAT-EPSILON
F383.LONG-FLOAT-NEGATIVE-EPSILON
F384.LONG-SITE-NAME
F385.LOOP
F386.LOWER-CASE-P
F387.MACHINE-INSTANCE
F388.MACHINE-TYPE
F389.MACHINE-VERSION
F390.MACRO-FUNCTION
F391.MACROEXPAND
F392.MACROEXPAND-1
F393.MACROEXPAND-HOOK
F394.MACROLET
F395.MAKE-ARRAY
F396.MAKE-BROADCAST-STREAM
F397.MAKE-CHAR
F398.MAKE-CONCATENATED-STREAM
F399.MAKE-DISPATCH-MACRO-CHARACTER
F400.MAKE-ECHO-STREAM
F401.MAKE-HASH-TABLE
F402.MAKE-LIST
F403.MAKE-PACKAGE
F404.MAKE-PATHNAME
F405.MAKE-RANDOM-STATE
F406.MAKE-SEQUENCE
F407.MAKE-STRING-INPUT-STREAM
F408.MAKE-STRING-OUTPUT-STREAM
F409.MAKE-STRING
F410.MAKE-SYMBOL
F411.MAKE-SYNONYM-STREAM
F412.MAKE-TWO-WAY-STREAM
F413.MAKUNBOUND
F414.MAP
F415.MAPC
F416.MAPCAN
F417.MAPCAR
F418.MAPCON
F419.MAPHASH
F420.MAPL
F421.MAPLIST
F422.MASK-FIELD
F423.MAX
F424.MEMBER
F425.MEMBER-IF
F426.MEMBER-IF-NOT
F427.MERGE
F428.MERGE-PATHNAMES
F429.MIN
F430.MINUSP
F431.MISMATCH
F432.MOD
F433.MODULES
F434.MOST-NEGATIVE-DOUBLE-FLOAT
F435.MOST-NEGATIVE-FIXNUM
F436.MOST-NEGATIVE-LONG-FLOAT
F437.MOST-NEGATIVE-SHORT-FLOAT
F438.MOST-NEGATIVE-SINGLE-FLOAT
F439.MOST-POSITIVE-DOUBLE-FLOAT
F440.MOST-POSITIVE-FIXNUM
F441.MOST-POSITIVE-LONG-FLOAT
F442.MOST-POSITIVE-SHORT-FLOAT
F443.MOST-POSITIVE-SINGLE-FLOAT
F444.MULTIPLE-VALUE-BIND
F445.MULTIPLE-VALUE-CALL
F446.MULTIPLE-VALUE-LIST
F447.MULTIPLE-VALUE-PROG1
F448.MULTIPLE-VALUE-SETQ
F449.MULTIPLE-VALUES-LIMIT
F450.NAME-CHAR
F451.NAMESTRING
F452.NBUTLAST
F453.NCONC
F454.NIL
F455.NINTERSECTION
F456.NINTH
F457.NOT
F458.NOTANY
F459.NOTEVERY
F460.NRECONC
F461.NREVERSE
F462.NSET-DIFFERENCE
F463.NSET-EXCLUSIVE-OR
F464.NSTRING-CAPITALIZE
F465.NSTRING-DOWNCASE
F466.NSTRING-UPCASE
F467.NSUBLIS
F468.NSUBST
F469.NSUBST-IF
F470.NSUBST-IF-NOT
F471.NSUBSTITUTE
F472.NSUBSTITUTE-IF
F473.NSUBSTITUTE-IF-NOT
F474.NTH
F475.NTHCDR
F476.NULL
F477.NUMBERP
F478.NUMERATOR
F479.NUNION
F480.ODDP
F481.OPEN
F482.OR
F483.OUTPUT-STREAM-P
F484.PACKAGE
F485.PACKAGE-NAME
F486.PACKAGE-NICKNAMES
F487.PACKAGE-SHADOWING-SYMBOLS
F488.PACKAGE-USE-LIST
F489.PACKAGE-USED-BY-LIST
F490.PACKAGEP
F491.PAIRLIS
F492.PARSE-INTEGER
F493.PARSE-NAMESTRING
F494.PATHNAME
F495.PATHNAME-DEVICE
F496.PATHNAME-DIRECTORY
F497.PATHNAME-HOST
F498.PATHNAME-NAME
F499.PATHNAME-TYPE
F500.PATHNAME-VERSION
F501.PATHNAMEP
F502.PEEK-CHAR
F503.PHASE
F504.PI
F505.PLUSP
F506.POP
F507.POSITION
F508.POSITION-IF
F509.POSITION-IF-NOT
F510.PPRINT
F511.PRIN1
F512.PRIN1-TO-STRING
F513.PRINC
F514.PRINC-TO-STRING
F515.PRINT
F516.PRINT-ARRAY
F517.PRINT-BASE
F518.PRINT-CASE
F519.PRINT-CIRCLE
F520.PRINT-ESCAPE
F521.PRINT-GENSYM
F522.PRINT-LENGTH
F523.PRINT-LEVEL
F524.PRINT-PRETTY
F525.PRINT-RADIX
F526.PROBE-FILE
F527.PROCLAIM
F528.PROG
F529.PROGSTAR
F530.PROG1
F531.PROG2
F532.PROGN
F533.PROGV
F534.PROVIDE
F535.PSETF
F536.PSETQ
F537.PUSH
F538.PUSHNEW
F539.QUERY-IO
F540.QUOTE
F541.RANDOM
F542.RANDOM-STATE
F543.RANDOM-STATE-P
F544.RASSOC
F545.RASSOC-IF
F546.RASSOC-IF-NOT
F547.RATIONAL
F548.RATIONALIZE
F549.RATIONALP
F550.READ
F551.READ-BASE
F552.READ-BYTE
F553.READ-CHAR-NO-HANG
F554.READ-CHAR
F555.READ-DEFAULT-FLOAT-FORMAT
F556.READ-DELIMITED-LIST
F557.READ-FROM-STRING
F558.READ-LINE
F559.READ-PRESERVING-WHITESPACE
F560.READ-SUPPRESS
F561.READTABLE
F562.READTABLEP
F563.REALPART
F564.REDUCE
F565.REM
F566.REMF
F567.REMHASH
F568.REMOVE
F569.REMOVE-DUPLICATES
F570.REMOVE-IF
F571.REMOVE-IF-NOT
F572.REMPROP
F573.RENAME-FILE
F574.RENAME-PACKAGE
F575.REPLACE
F576.REQUIRE
F577.REST
F578.RETURN
F579.RETURN-FROM
F580.REVAPPEND
F581.REVERSE
F582.ROOM
F583.ROTATEF
F584.ROUND
F585.RPLACA
F586.RPLACD
F587.SBIT
F588.SCALE-FLOAT
F589.SCHAR
F590.SEARCH
F591.SECOND
F592.SET
F593.SET-CHAR-BIT
F594.SET-DIFFERENCE
F595.SET-DISPATCH-MACRO-CHARACTER
F596.SET-EXCLUSIVE-OR
F597.SET-MACRO-CHARACTER
F598.SET-SYNTAX-FROM-CHAR
F599.SETF
F600.SETQ
F601.SEVENTH
F602.SHADOW
F603.SHADOWING-IMPORT
F604.SHIFTF
F605.SHORT-FLOAT-EPSILON
F606.SHORT-FLOAT-NEGATIVE-EPSILON
F607.SHORT-SITE-NAME
F608.SIGNUM
F609.SIMPLE-BIT-VECTOR-P
F610.SIMPLE-STRING-P
F611.SIMPLE-VECTOR-P
F612.SIN
F613.SINGLE-FLOAT-EPSILON
F614.SINGLE-FLOAT-NEGATIVE-EPSILON
F615.SINH
F616.SIXTH
F617.SLEEP
F618.SOFTWARE-TYPE
F619.SOFTWARE-VERSION
F620.SOME
F621.SORT
F622.SPECIAL-FORM-P
F623.SQRT
F624.STABLE-SORT
F625.STANDARD-CHAR-P
F626.STANDARD-INPUT
F627.STANDARD-OUTPUT
F628.STEP
F629.STREAM-ELEMENT-TYPE
F630.STREAMP
F631.STRING
F632.STRING-CAPITALIZE
F633.STRING-CHAR-P
F634.STRING-DOWNCASE
F635.STRING-EQUAL
F636.STRING-GREATERP
F637.STRING-LEFT-TRIM
F638.STRING-LESSP
F639.STRING-NOT-EQUAL
F640.STRING-NOT-GREATERP
F641.STRING-NOT-LESSP
F642.STRING-RIGHT-TRIM
F643.STRING-TRIM
F644.STRING-UPCASE
F645.STRINGSLASHEQSIGN
F646.STRINGLESSTHANEQSIGN
F647.STRINGLESSTHAN
F648.STRINGEQSIGN
F649.STRINGGTRTHANEQSIGN
F650.STRINGGTRTHAN
F651.STRINGP
F652.SUBLIS
F653.SUBSEQ
F654.SUBSETP
F655.SUBST
F656.SUBST-IF
F657.SUBST-IF-NOT
F658.SUBSTITUTE
F659.SUBSTITUTE-IF
F660.SUBSTITUTE-IF-NOT
F661.SUBTYPEP
F662.SVREF
F663.SXHASH
F664.SYMBOL-FUNCTION
F665.SYMBOL-NAME
F666.SYMBOL-PACKAGE
F667.SYMBOL-PLIST
F668.SYMBOL-VALUE
F669.SYMBOLP
F670.T
F671.TAGBODY
F672.TAILP
F673.TANH
F674.TAN
F675.TENTH
F676.TERMINAL-IO
F677.TERPRI
F678.THE
F679.THIRD
F680.THROW
F681.TIME
F682.TRACE
F683.TRACE-OUTPUT
F684.TREE-EQUAL
F685.TRUENAME
F686.TRUNCATE
F687.TYPE-OF
F688.TYPECASE
F689.TYPEP
F690.UNEXPORT
F691.UNINTERN
F692.UNION
F693.UNLESS
F694.UNREAD-CHAR
F695.UNTRACE
F696.UNUSE-PACKAGE
F697.UNWIND-PROTECT
F698.UPPER-CASE-P
F699.USE-PACKAGE
F700.USER-HOMEDIR-PATHNAME
F701.VALUES
F702.VALUES-LIST
F703.VECTOR
F704.VECTOR-POP
F705.VECTOR-PUSH
F706.VECTOR-PUSH-EXTEND
F707.VECTORP
F708.WARN
F709.WHEN
F710.WITH-INPUT-FROM-STRING
F711.WITH-OPEN-FILE
F712.WITH-OPEN-STREAM
F713.WITH-OUTPUT-TO-STRING
F714.WRITE
F715.WRITE-BYTE
F716.WRITE-CHAR
F717.WRITE-LINE
F718.WRITE-STRING
F719.WRITE-TO-STRING
F720.Y-OR-N-P
F721.YES-OR-NO-P
F722.ZEROP
F750.ROW-MAJOR-AREF
F751.UPGRADED-ARRAY-ELEMENT-TYPE
F752.UPGRADED-COMPLEX-PART-TYPE
F753.DEFPACKAGE
F754.DESCRIBE-OBJECT
F755.DESTRUCTURING-BIND
F756.COMPLEMENT
F757.FUNCTION-LAMBDA-EXPRESSION
F758.FDEFINITION
F759.GENSYM-COUNTER
F760.HASH-TABLE-REHASH-SIZE
F761.HASH-TABLE-REHASH-THRESHOLD
F762.HASH-TABLE-SIZE
F763.HASH-TABLE-TEST
F764.WITH-HASH-TABLE-ITERATOR
F765.WITH-PACKAGE-ITERATOR
F766.NTH-VALUE
F767.DELETE-PACKAGE
F768.REALP
F769.OPEN-STREAM-P
F770.BROADCAST-STREAM-STREAMS
F771.CONCATENATED-STREAM-STREAMS
F772.ECHO-STREAM-INPUT-STREAM
F773.ECHO-STREAM-OUTPUT-STREAM
F774.SYNONYM-STREAM-SYMBOL
F775.TWO-WAY-STREAM-INPUT-STREAM
F800.ABORT
F801.ARITHMETIC-ERROR-OPERANDS
F802.ARITHMETIC-ERROR-OPERATION
F803.ASSERT
F804.BREAK
F805.BREAK-ON-SIGNALS
F806.BREAK-ON-WARNINGS
F807.CCASE
F808.CELL-ERROR-NAME
F809.CERROR
F810.CHECK-TYPE
F811.COMPUTE-RESTARTS
F812.CONTINUE
F813.CTYPECASE
F814.DEBUGGER-HOOK
F815.DEFINE-CONDITION
F816.ECASE
F817.ERROR
F818.ETYPECASE
F819.FILE-ERROR-PATHNAME
F820.FIND-RESTART
F821.HANDLER-BIND
F822.HANDLER-CASE
F823.IGNORE-ERRORS
F824.INVOKE-DEBUGGER
F825.INVOKE-RESTART-INTERACTIVELY
F826.INVOKE-RESTART
F827.MAKE-CONDITION
F828.MUFFLE-WARNING
F829.PACKAGE-ERROR-PACKAGE
F830.RESTART-BIND
F831.RESTART-CASE
F832.RESTART-NAME
F833.SIGNAL
F834.SIMPLE-CONDITION-FORMAT-ARGUMENTS
F835.SIMPLE-CONDITION-FORMAT-STRING
F836.STORE-VALUE
F837.STREAM-ERROR-STREAM
F838.TYPE-ERROR-DATUM
F839.TYPE-ERROR-EXPECTED-TYPE
F840.USE-VALUE
F841.WARN
F842.WITH-SIMPLE-RESTART
F900.ADD-METHOD
F901.CALL-METHOD
F902.CALL-NEXT-METHOD
F903.CHANGE-CLASS
F904.CLASS-NAME
F905.CLASS-OF
F906.COMPUTE-APPLICABLE-METHODS
F907.DEFCLASS
F908.DEFGENERIC
F909.DEFINE-METHOD-COMBINATION
F910.DEFMETHOD
F911.DESCRIBE
F912.DOCUMENTATION
F913.ENSURE-GENERIC-FUNCTION
F914.FIND-CLASS
F915.FIND-METHOD
F916.FUNCTION-KEYWORDS
F917.GENERIC-FLET
F918.GENERIC-FUNCTION
F919.GENERIC-LABELS
F920.INITIALIZE-INSTANCE
F921.INVALID-METHOD-ERROR
F922.MAKE-INSTANCE
F923.MAKE-INSTANCES-OBSOLETE
F924.METHOD-COMBINATION-ERROR
F925.METHOD-QUALIFIERS
F926.NEXT-METHOD-P
F927.NO-APPLICABLE-METHOD
F928.NO-NEXT-METHOD
F929.PRINT-OBJECT
F930.REINITIALIZE-INSTANCE
F931.REMOVE-METHOD
F932.SHARED-INITIALIZE
F933.SLOT-BOUNDP
F934.SLOT-EXISTS-P
F935.SLOT-MAKUNBOUND
F936.SLOT-MISSING
F937.SLOT-UNBOUND
F938.SLOT-VALUE
F939.SYMBOL-MACROLET
F940.UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
F941.UPDATE-INSTANCE-FOR-REDEFINED-CLASS
F942.WITH-ACCESSORS
F943.WITH-ADDED-METHODS
F944.WITH-SLOTS
F945.SETF-CLASS-NAME
F946.SETF-DOCUMENTATION
S1100.SCOPE-PURPOSE-AND-HISTORY
S1200.ORGANIZATION-OF-THE-DOCUMENT
S1300.REFERENCED-PUBLICATIONS
S1400.DEFINITIONS
S1500.COMPLIANCE
S1600.LANGUAGE-EXTENSIONS
S2100.INTRODUCTION
S2200.TYPES
S2300.CLASSES
S2400.SLOTS
S2500.OBJECTS
S3100.CHARACTER-READER
S3200.OBJECT-SYNTAX
S4100.EVALUATION-MODEL
S4200.COMPILATION
S5100.ERRORS
S5200.INPUT-OUTPUT
S5300.INTERFACE-WITH-PROGRAMMING-ENVIRONMENT
S5400.GENERALIZED-REFERENCE
S5500.PREDICATES
S6100.INTRODUCTION
SA100.IMPLEMENTATION-DEFINED-FEATURES
SA200.PORTABILITY-ISSUES
SA300.REMOVED-DEFINED-NAMES
SA400.DEPRECATED-DEFINED-NAMES
∂03-May-89 0531 Quinquevirate-mailer checked out status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 89 05:30:16 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA21008; Wed, 3 May 89 05:31:12 PDT
Message-Id: <8905031231.AA21008@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA21008; Wed, 3 May 89 05:31:12 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 May 89 08:29
To: quinquevirate@sail.stanford.edu
Subject: checked out status
Section Who has Date out
1.1 KC
1.2 KC
1.3 KC
1.4 KC
1.5 KC
1.6 KC
2.1
2.2 KC
3.1 KC
3.2 KC
4.1 KC
4.2
5.1 RPG 4/7/89
5.2 Masinter 4/7/89
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1 RPG 4/12/89
Glossary KC
CLOS RPG 5/2/89
PREDICATES Masinter 5/3/89
STRINGS Masinter 5/3/89
SEQUENCES Masinter 5/3/89
LISTS Masinter 5/3/89
NUMBERS Masinter 5/3/89
STRUCTURES GLS 5/3/89
SYMBOLS GLS 5/3/89
HASHTABLES GLS 5/3/
ARRAYS GLS 5/3/89
TYPES GLS 5/3/89
DECLARATIONS GLS 5/3/89
IO KC
STREAMS KC
FILE KC
CONTROL KC
PROGRAM KC
MISC KC
ERRORS KC
MACROS KC
PACKAGES KC
CHARACTERS KC
EVALUATOR KC
∂03-May-89 1143 Quinquevirate-mailer file name/number mapping
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 3 May 89 11:43:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 589085; 3 May 89 13:54:52 EDT
Date: Wed, 3 May 89 13:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: file name/number mapping
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8905031129.AA17913@decwrl.dec.com>
Message-ID: <19890503175448.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I couldn't figure out what you wanted me to do with this 874 line
message so I just deleted it.
∂03-May-89 1515 Quinquevirate-mailer Re: new cleanups
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 May 89 15:14:08 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 03 MAY 89 15:08:54 PDT
Date: 3 May 89 15:07 PDT
From: masinter.pa@Xerox.COM
Subject: Re: new cleanups
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Tue, 2 May 89 07:04:46 MDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: masinter.pa@Xerox.COM, quinquevirate@sail.stanford.edu
Message-ID: <890503-150854-10754@Xerox>
Users can rely on EVALHOOK more than they can rely on BREAK. EVALHOOK is
defined as 'a facility that is useful when it makes sense'. Conformal
implementations should be constrained to clearly document whether their
implementation is 'interpreted' or 'compiled', and EVALHOOK's behavior is
well specified: it affects evaluation of 'interpreted' forms and does not
affect the evaluation of 'compiled' forms. It is not true that "... users
can't rely on EVALHOOK doing anything meaningful." It is true that the
behavior of EVALHOOK can vary, in certain well constrained ways, from one
implementation to the next.
∂05-May-89 1908 Quinquevirate-mailer checked out status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 5 May 89 19:08:10 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA24368; Fri, 5 May 89 13:54:45 PDT
Message-Id: <8905052054.AA24368@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA24368; Fri, 5 May 89 13:54:45 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 5 May 89 16:51
To: quinquevirate@sail.stanford.edu
Subject: checked out status
Section Who has Date out
1.1 RPG 5/5/89
1.2 KC
1.3 KC
1.4 KC
1.5 KC
1.6 KC
2.1 KC
2.2 Moon 5/5/89
2.3 RPG 5/5/89
2.4 RPG 5/5/89
2.5 RPG 5/5/89
3.1 Masinter 5/5/89
3.2 Masinter 5/5/89
3.3 Masinter 5/5/89
3.4 Masinter 5/5/89
4.1 Moon 5/5/89
4.2 KC
5.1 RPG 4/7/89
5.2 Masinter 4/7/89
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1 RPG 5/5/89
Glossary KC
CLOS RPG 5/2/89
PREDICATES Masinter 5/3/89
STRINGS Masinter 5/3/89
SEQUENCES Masinter 5/3/89
LISTS Masinter 5/3/89
NUMBERS Masinter 5/3/89
STRUCTURES GLS 5/3/89
SYMBOLS GLS 5/3/89
HASHTABLES GLS 5/3/89
ARRAYS GLS 5/3/89
TYPES GLS 5/3/89
DECLARATIONS GLS 5/3/89
IO KC
STREAMS KC
FILE KC
CONTROL KC
PROGRAM KC
MISC KC
ERRORS Moon 5/4/89
MACROS Moon 5/4/89
PACKAGES Moon 5/4/89
CHARACTERS Moon 5/4/89
EVALUATOR Moon 5/4/89
∂08-May-89 1430 Quinquevirate-mailer answers to your questions
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 8 May 89 14:30:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 591736; 8 May 89 17:30:35 EDT
Date: Mon, 8 May 89 17:30 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: answers to your questions
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8905052001.AA21503@decwrl.dec.com>
Supersedes: <19890508210023.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19890508211636.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Please disregard the earlier version of this message.
I was interrupted while composing it and I forgot to include
one paragraph (about subclass) that I had intended to include.
This time I spelled the name of the mailing list right
Message-ID: <19890508213041.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I decided I better CC these answers to quinqevirate as an extra check
on my accuracy.
Date: 5 May 89 15:52
From: chapman%aitg.DEC@decwrl.dec.com
Following are some further questions on 2.2, the 4.1 source file
has more questions (preceded by "***").
>Subj: comments on comments on section 2.2
> >p.2-32ff: the many type specifiers added by CLOS are missing, including
> >EQL, the new built-in types like STANDARD-OBJECT and GENERIC-FUNCTION,
> >and the ability to use a class object as a type-specifier.
> I will need some help figuring out how the CLOS types fit here. I had
> planned to generate a clean-up about this and the Condition System
> types after Gregor(?) and KMP help me construct this correctly. Maybe
> it's straightforward, but when I started to do it on my own I ran into
> too many questions.
>
>It shouldn't be necessary to make any decisions, but you may need some
>help decoding the existing documents. I'll be happy to answer any questions
>you have. I don't think a Cleanup should be necessary, as the types have
>already been put into the language by acceptance of earlier documents.
>All we have to do is gather the existing information into a single place
>and put it into a uniform format. I believe none of the CLOS and Condition
>type specifiers take arguments, which makes things simpler.
1. Where can I find the type hierarchy for standard-object, standard-class,
built-in-class, and standard-object?
Here's some material from a draft of chapter 3. This much I believe.
STRUCTURE-OBJECT, STANDARD-OBJECT, GENERIC-FUNCTION, METHOD,
METHOD-COMBINATION, and CLASS are disjoint and each has superclass T.
STANDARD-CLASS, STRUCTURE-CLASS, BUILT-IN-CLASS,
STANDARD-GENERIC-FUNCTION, and STANDARD-METHOD are disjoint and have
superclass CLASS, CLASS, CLASS, GENERIC-FUNCTION, and METHOD
respectively. No exhaustive partitions here. Those are all the classes
I could find in 88-002R; chapter 3 adds some more but we can forget
about them for now.
I don't know why STRUCTURE-OBJECT isn't named STRUCTURE (the name
Symbolics Genera uses). The symbol STRUCTURE already exists in
CLtL Common Lisp (as a word used by the DOCUMENTATION function),
so it seems like the appropriate word.
2. Which classes are actually defined be the CLOS chapters we accepted and
which ones are part of Chapter 3? Are we including some info from Chapter 3
to make the parts we accepted make more sense?
See above.
This doesn't settle all the chapter 2 versus chapter 3 questions, e.g. what
good is ADD-METHOD without chapter 3. I don't want to think about those now.
3. What is the supertype of types RESTART and CONDITION (t, I assume)?
In most implementations, it will probably really be STANDARD-OBJECT, but I
guess the spec should only say T; similar to PATHNAME, RESTART and CONDITION
should be implementable as builtin, structure, or standard class at the
implementor's discretion.
What is the
relationship of the condition system data types to each other (disjoint,
exhaustive partition, ...)?
CONDITION and RESTART, like PATHNAME, are disjoint with everything else,
and with each other. The subtypes of CONDITION have defined relationships
in the condition system document, if I remember correctly.
>p.2-5 second bullet from the bottom: This extends a CLtL comment about
>DEFSTRUCT to DEFCLASS. However, it does not work for DEFCLASS because
>of multiple superclasses. Two classes A and B can have a common subclass
>C, even though A is not a superclass of B and B is not a superclass of A.
>In this case A and B are not disjoint. What you want to say instead is
>that the type relations explicitly created by specifying superclasses
>are the only type relations, or words to that effect.
How about these words:
"Any two {\word classes\/} created by {\function defclass\/}
are related only by
the type relations explicitly created by the {\word superclasses\/} specified
during class creation."
>Okay except I would change "by the type relations explicitly created by"
>to "according to". But maybe this would be better: "Any two {\word
>classes\/} created by {\function defclass\/} are {\word disjoint}
>unless they have a common {\word superclass}." [That assumes that
>our definition of superclass says every class is a superclass of
>itself, which I think is the case, but did not check.]
CLOS (and now section 2.3) says "A class is considered neither a
superclass nor a subclass of itself." So I used "according to".
You lost the context of this remark. I've restored it above, since I
fortunately hadn't gotten around to deleting the mail yet. The wording
you chose is not wrong, but I still think it's a pity we don't have a
term that includes a class as well as its superclasses, so that we can
use the much more explicit wording I suggested. The Flavors word for
this is "component". Even without such a term, I think we could say:
"Any two {\word classes\/} created by {\function defclass\/} are {\word
disjoint} unless they have a common {\word superclass} or one {\word
class} is a {\word superclass} of the other."
Also I think it may be perceived as odd that a type is a subtype and
a supertype of itself (CLtL p.72), but a class is not a subclass nor
a superclass of itself. We can't really change the nomenclature for
types, since it derives directly from the mathematics of sets. I'm
not sure what would be the impact of changing the nomenclature for
classes so that what is now "subclass" would become "proper subclass",
and what is now "superclass" would become "proper superclass". This
would (clearly) not affect "direct subclass" and "direct superclass".
>Now somewhere in 6.1: The reference to APL is questionable, does this mean
>we are incorporating some specific standard by reference (then we should
>give its exact name), or is it just a general remark?
I cited the whole reference this time.
It still doesn't tell me how to order a copy, or is that in a bibliography
elsewhere?
I'll let Guy Steele be the arbiter on this one, but I'm not sure that we want to
just refer to another standard instead of giving the branch cut rules explicitly.
There is too much room for ambiguity or mistakes in mapping between APL and Lisp.
Maybe the branch cut rules are given explicitly, but I haven't been able to find
them. After mentioning the APL document, section 6.1 goes off to talk about
something unrelated.
Section 4.1:
[If an operator symbol doesn't name a function, special form, or macro]
An error of type {\datatype undefined-function\/} might be signalled.
*** I have recorded that the issue UNDEFINED-VARIABLES-AND-FUNCTIONS
has been withdrawn. So I guess we can't adopt its contents, but what
about ``might'' in place of ``should''?
My notes say it's deferred to the June meeting to fix the CLOS slot
part, not withdrawn. That's independent of the function part, and I
think "should" would be best here (as UNDEFINED-VARIABLES-AND-FUNCTIONS
proposes). Can we just change it to "should" or do we have to go
through the cleanup committee?
\itemitem{{\bf Apply:\/} returns the result of the evaluation of the last form
in the lambda body}
*** Moon's comment is that {\function apply\/} is also referenced for
named functions. What to do here?***
Following is the algorithm for {\bf apply\/}.
\beginlist
\itemitem{1.} Find all declarations.
\itemitem{2.} Create new dynamic and lexical contexts.
*** David, please suggest a fix for this.***
\itemitem{3.}{\bf Evaluate forms\/} in the lambda body in the lexical and
dynamic contexts.
Well, I think APPLY is a way of getting some arguments to a function,
and shouldn't say anything about what happens inside the function.
Thus parameter matching, declarations, environments ("contexts"), and
forms in the body shouldn't be mentioned in connection with APPLY.
Maybe APPLY is just completely the wrong word here, and APPLY-LAMBDA
is the word JAR should have used.
The stuff listed here under APPLY correctly belongs under a description
of "calling a lambda", something that both APPLY and FUNCALL do.
Except, we don't call lambdas, we call functions, and lambdas aren't
functions. I couldn't find anything in section 4.1 that was clear about
this, although I was hampered by only looking at TeX source. Thus I
couldn't find the right name for this. What you are trying to describe is
the semantics of calling a user defined function, regardless of whether
that function is defined with DEFUN, FLET, or LAMBDA, and independent of
whether the semantics are implemented by an interpreter or a compiler
(thus independent of whether all the actions are happening at the time
the function is called, or some happened ahead of time). That's all the
help I can offer right now, I sure hope it's enough.
BTW section 4.1 still appears to suffer from saying everything twice,
although it's hard to be sure when reading TeX source. I guess that's
the import of
*** David, please suggest where you want this information to go***
What I want is not for the text attached to that to be moved someplace
else, but to merge or eliminate the duplicated descriptions. For
example, \beginsubsubsection{Symbols as Forms} is about the same topic
as \itemitem{{\bf Variable evaluation:}, and each of them says something
about that topic that the other one fails to say. The two pieces of
text need to be combined and cast into a consistent style, without losing
any of the contained information. Similarly for evaluation of the other
kinds of forms. I don't think I can do this rewriting myself.
∂11-May-89 0725 Quinquevirate-mailer responses to your answers]
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 11 May 89 07:25:42 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA28207; Thu, 11 May 89 07:26:49 PDT
Message-Id: <8905111426.AA28207@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA28207; Thu, 11 May 89 07:26:49 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 11 May 89 10:16
To: @MOON@decwrl.dec.com, quinquevirate@sail.stanford.edu
Subject: responses to your answers]
> >Now somewhere in 6.1: The reference to APL is questionable, does this mean
> >we are incorporating some specific standard by reference (then we should
> >give its exact name), or is it just a general remark?
> I cited the whole reference this time.
>It still doesn't tell me how to order a copy, or is that in a bibliography
>elsewhere?
I put the reference to the book in section 1.3 and cited that book in
place of the acronym.
>I'll let Guy Steele be the arbiter on this one, but I'm not sure that we want to
>just refer to another standard instead of giving the branch cut rules explicitly.
>There is too much room for ambiguity or mistakes in mapping between APL and Lisp.
>Maybe the branch cut rules are given explicitly, but I haven't been able to find
>them. After mentioning the APL document, section 6.1 goes off to talk about
>something unrelated.
The branch cut rules that were in CLtL are located with the descriptions
of the functions to which they apply. Is that organization sensible? Are
there more branch cut rules in the reference that should be explicitly
stated in the standard?
>Section 4.1:
>
> [If an operator symbol doesn't name a function, special form, or macro]
> An error of type {\datatype undefined-function\/} might be signalled.
> *** I have recorded that the issue UNDEFINED-VARIABLES-AND-FUNCTIONS
> has been withdrawn. So I guess we can't adopt its contents, but what
> about ``might'' in place of ``should''?
>
>My notes say it's deferred to the June meeting to fix the CLOS slot
>part, not withdrawn. That's independent of the function part, and I
>think "should" would be best here (as UNDEFINED-VARIABLES-AND-FUNCTIONS
>proposes). Can we just change it to "should" or do we have to go
>through the cleanup committee?
Seems like `should' was a critical part of this proposal. But we could
assume this will pass and use `should' here, then take it out if it doesn't?
∂15-May-89 0342 Quinquevirate-mailer Compiler section (4.2)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 May 89 03:41:52 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA24115; Mon, 15 May 89 03:42:45 PDT
Message-Id: <8905151042.AA24115@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA24115; Mon, 15 May 89 03:42:45 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 May 89 06:40
To: quinquevirate@sail.stanford.edu
Subject: Compiler section (4.2)
This section was written by Sandra and reviewed by RPG. Any other comments
before I begin working on it?
kathy
[rpg: Comments look like this.]
Introduction
============
The compiler is a utility that translates programs into an
implementation-dependent form that can be represented and/or executed
more efficiently. The nature of the processing performed during
compilation is discussed in the "Compilation Semantics" section below.
This is followed by a discussion of the behavior of COMPILE-FILE and
the interface between COMPILE-FILE and LOAD.
[rpg:
The compiler is a utility that may translate programs into an
implementation-dependent form that might be represented or executed
more efficiently. The nature of the processing performed during
compilation is discussed in the "Compilation Semantics" section below.
This is followed by a discussion of the behavior of COMPILE-FILE and
the interface between COMPILE-FILE and LOAD.
]
% References:
% CLtL page 143 (next to last paragraph)
% CLtL page 321 (second paragraph)
[rpg: CLtL page 438]
The functions COMPILE and COMPILE-FILE are used to explicitly force
[rpg: yuck] compilation to take place. It is permissible for
conforming implementations to also perform implicit compilation during
ordinary evaluation. While the evaluator is typically implemented as
an interpreter that traverses the given form recursively, performing
each step of the computation as it goes, a permissible alternate
approach is for the evaluator first to completely compile the form
into machine-executable code and then invoke the resulting code.
Various mixed strategies are also possible. All of these approaches
should produce the same results when executing a correct program, but
may produce different results for incorrect programs.
[rpg: This should say that execution of programs can be accomplished
by a variety of means ranging from direct interpretation of the list
structure representing a program through compilation to machine code,
and that the designer of an interpreter (evaluator?) can select any
of these strategies, and the designer of the compiler should select
any strategy that generally results in code that is no slower or no
bigger and which satisfies the constraints just below.]
% This paragraph should really conclude with a stronger statement that
% conforming programs must be structured so they will work if implicit
% compilation does take place, but CLtL doesn't come right out and say
% that, and we have never voted on any issue to say that either.
Compilation Semantics
=====================
% References:
% Issue COMPILE-ENVIRONMENT-CONSISTENCY [pending]
% Issue COMPILED-FUNCTION-REQUIREMENTS [pending]
% The material in this section will have to be updated to reflect further
% changes to these issues.
Conceptually, compilation can be viewed as a process which traverses a
program, performs certain kinds of syntactic and semantic analysis
using information (such as proclamations and macro definitions)
present in the compile time environment, and produces a modified
program. As a minimum, the compiler must perform the following
actions:
- All macro calls appearing lexically within the code being compiled
must be expanded at compile time and will not be expanded again at
run time. The process of compilation effectively turns MACROLET
and SYMBOL-MACROLET constructs int PROGNs, with all calls to the local
macros in the body replaced by their expansions.
The compiler must treat any form that is a list beginning with a
symbol that does not name a macro or special form as a function call.
(This implies that SETF methods must also be available at compile time.)
- The compiler must capture declarations to determine whether
variable bindings and references appearing lexically within the
code being compiled are to be treated as lexical or special. The
compiler must treat any binding of a variable that has not been
declared or proclaimed to be SPECIAL as a lexical binding.
- The compiler must process EVAL-WHEN forms that appear lexically within
the program being compiled. Effectively, the compiler must replace
the EVAL-WHEN form with either a PROGN containing the body forms, or
a constant NIL.
- The compiler must process LOAD-TIME-VALUE forms that appear lexically
within the program being compiled. In the case of COMPILE, evaluation
of the LOAD-TIME-VALUE form happens at compile time and the resulting
value is treated as a literal constant at run time. In the case of
COMPILE-FILE, the compiler must arrange for evaluation of the form
to take place at load time.
In addition, the compiler is permitted to incorporate the following
kinds of information into the code it produces, if the information is
present in the compile time environment and is referenced within the
code being compiled. Except where some other behavior is explicitly
stated, when the compile time and run time definitions are different,
it is unspecified which will prevail within the compiled code. It is
also permissible for implementations to signal an error at run time to
complain about the discrepancy. [rpg: Diction.] In all cases, the
absence of the information at compile time is not an error, [rpg:
terminology] but its presence may enable the compiler to generate more
efficient code.
[rpg: There is a complicated issue: Can the compiler assume that the
resulting code in a compile-file situation will be run in the same
Lisp? The same implementation? The same computer? The same type of
computer?
I suggest that we say that the semantics we discuss presumes that the
compiler can assume that when doing compile-file that the resulting
code will be loaded into a fresh copy of the same Lisp.]
- The compiler may assume that functions that are defined and
declared or proclaimed INLINE in the compile time environment will
retain the same definitions at run time.
- The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
[rpg: the interpreter can assume the same thing, right? That is, a
valid Common Lisp has be one in all code is compile-filed by a
separate program and loaded and executed in the apparent Common Lisp
image.]
- COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at run time.
[rpg: the interpreter can assume the same thing, right?]
- The compiler may assume that the argument syntax and number of return
values for all built-in Common Lisp functions will not change. In
addition, the compiler may treat all built-in Common Lisp functions
as if they had been proclaimed INLINE.
[rpg: the interpreter can assume the same thing, right? This follows from
LISP-SYMBOL-REDEFINITION.]
- The compiler may assume that the argument syntax and number of return
values for all functions with FTYPE information available at
compile time will remain the same at run time.
% Reference: CLtL page 69
- The compiler may assume that symbolic constants that have been
defined with DEFCONSTANT in the compile time environment will retain
the same value at run time as at compile time. The compiler may replace
references to the name of the constant with the value of the constant,
provided that such "copies" are EQL to the object that is the
actual value of the constant.
% The following paragraph from issue COMPILE-ENVIRONMENT-CONSISTENCY
% seems likely to change:
- The compiler can assume that type definitions made with DEFTYPE
or DEFSTRUCT in the compile time environment will retain the same
definition in the run time environment. It may also assume that
a class defined by DEFCLASS in the compile time environment will
be defined in the run time environment in such a way as to have
the same superclasses and metaclass. [rpg: compatible metaclass?]
[rpg: This is a little curious. Is this talking only about this sort of case:
(defclass c ...)
(compile-file <something using c>)
or is it trying to cover the case of
(compile-file <...(declass c ...) ... something using c>)
]
This implies that
subtype/supertype relationships of type specifiers will not
change between compile time and run time. (Note that it is not
an error [rpg: terminology?] for an unknown type to appear in a
declaration at
compile time, although it is reasonable for the compiler to
emit a warning in such a case.)
% Ref: CLtL page 153
- The compiler may assume that if type declarations are present
in the compile time environment, the corresponding variables and
functions present in the run time environment will actually be of
those types; otherwise, the run time behavior of the program is
undefined.
The compiler *must not* make any additional assumptions about
consistency between the compile time and run time environments. In
particular:
- The compiler may not assume that functions that are defined
in the compile time environment will retain the either the
same definition or the same signature at run time, except in the
situations explicitly listed above.
- The compiler may not signal an error if it sees a call to a
function that is not defined at compile time, since that function
may be provided at run time.
File Compilation
================
The function COMPILE-FILE performs compilation processing (described
in the previous section) on forms appearing in a file, producing an
output file which may then be loaded with LOAD.
Normally, the top-level forms appearing in a file compiled with
COMPILE-FILE are executed only when the resulting compiled file is
loaded, and not when the file is compiled. However, it often happens
that some forms in the file must be evaluated at compile time in order
for the remainder of the file to be read and compiled correctly; for
example, forms that change the values of *PACKAGE* or *READTABLE* and
macro definitions. In such cases, the distinction between processing
that is performed at compile time and processing that is performed at
load time becomes important.
The special form EVAL-WHEN can be used to give explicit control over
the time at which evaluation of a top-level form takes place, allowing
forms to be executed at compile time, load time, or both. The
behavior of this construct may be more precisely understood in terms
of a model of how COMPILE-FILE processes forms in a file to be
compiled.
Successive forms are read from the file by the file compiler [rpg:
COMPILE-FILE] using READ. These top-level forms are normally processed
in what we call `not-compile-time' mode; in this mode, the file
compiler arranges for forms to be evaluated only at load time and not
at compile time. There is one other mode, called `compile-time-too'
mode, in which forms are evaluated both at compile and load times.
[rpg: what is the file compiler? The thing that compile-file causes to
run?
Also, isn't this requirement that COMPILE-FILE to use READ new? I don't
see why it's required. I suggest removing it.]
Processing of top-level forms in the file compiler works as follows:
* If the form is a macro call, it is expanded and the result is
processed as a top-level form in the same processing mode
(compile-time-too or not-compile-time).
* If the form is a PROGN form, each of its body forms is
sequentially processed as top-level forms in the same processing
mode.
* If the form is a LOCALLY, MACROLET, or SYMBOL-MACROLET,
the file compiler makes the appropriate bindings and recursively
processes the body forms as an implicit top-level PROGN with those
bindings in effect, in the same processing mode. (Note that this
implies that the lexical environment in which top-level forms are
processed is not necessarily the null lexical environment.)
* If the form is an EVAL-WHEN form, it is handled according to
the following table:
:COMPILE- :LOAD- :EXECUTE compile-time-too Action
TOPLEVEL TOPLEVEL
Yes Yes -- -- Process body in compile-time-too mode
No Yes Yes Yes Process body in compile-time-too mode
No Yes Yes No Process body in not-compile-time mode
No Yes No -- Process body in not-compile-time mode
Yes No -- -- Evaluate body
No No Yes Yes Evaluate body
No No Yes No do nothing
No No No -- do nothing
"Process body" means to process the body (using the procedure
outlined in this subsection) as an implicit top-level PROGN.
"Evaluate body" means to evaluate the body forms as an implicit
PROGN in the dynamic execution context of the compiler and in the
lexical environment in which the EVAL-WHEN appears.
* Otherwise, the form is a top-level form that is not one of the
special cases. If in compile-time-too mode, the compiler first
evaluates the form and then performs normal compiler processing
on it. If in not-compile-time mode, only normal compiler
processing is performed. Any subforms are treated as non-top-level
forms.
Note that top-level forms are processed in the order in which they
textually appear in the file, and that each top-level form read by the
compiler is processed before the next is read. However, the order of
processing (including, in particular, macro expansion) of subforms
that are not top-level forms is unspecified.
EVAL-WHEN forms cause compile time evaluation only at top-level. In
non-top-level locations, both the :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL
situations are ignored and only the :EXECUTE situation is considered.
The following macros make definitions that are typically used during
compilation and are defined to make those definitions available at
both compile time and run time when calls to those macros appear in a
file being compiled. As with EVAL-WHEN, these compile time
side-effects happen only when the defining macros appear at top-level.
% The specific details of the compile time side effects should go under
% the description of the macro in chapters 6 & 7.
DEFTYPE
DEFMACRO
DEFINE-MODIFY-MACRO
DEFVAR
DEFPARAMETER
DEFCONSTANT
DEFSETF
DEFINE-SETF-METHOD
DEFSTRUCT
DEFINE-CONDITION
DEFPACKAGE
IN-PACKAGE
% These depend on the outcome of issue CLOS-MACRO-COMPILATION
DEFCLASS
DEFGENERIC
DEFMETHOD
DEFINE-METHOD-COMBINATION
% This depends on the outcome of issue PROCLAIM-ETC-IN-COMPILE-FILE
DEFPROCLAIM
The compile time behavior of these macros can be understood as if
their expansions effectively include (EVAL-WHEN (:COMPILE-TOPLEVEL)
...) forms. It is not required that the compile time definition be
made in the same manner as if the defining macro had been evaluated
directly. In particular, the information stored by the defining
macros at compile time may or may not be available to the evaluator
(either during or after compilation), or during subsequent calls to
COMPILE or COMPILE-FILE. If the definition must be visible during
compile time evaluation, it should be placed within an explicit
(EVAL-WHEN (:COMPILE-TOPLEVEL) ...) to ensure that it will be fully
defined at compile time.
Wrong: (defmacro foo (x) `(car ,x))
(eval-when (:execute :compile-toplevel :load-toplevel)
(print (foo '(a b c))))
Right: (eval-when (:execute :compile-toplevel :load-toplevel)
(defmacro foo (x) `(car ,x))
(print (foo '(a b c))))
Compiler/Loader Interface
=========================
% Reference: Issue QUOTE-SEMANTICS
The functions EVAL and COMPILE always ensure that constants referenced
within the resulting interpreted or compiled code objects are EQL to
the corresponding objects in the source code. COMPILE-FILE, on the
other hand, must produce an output file which contains instructions
[rpg: to] tell the loader how to reconstruct the objects appearing in
the source code when the compiled file is loaded.
[rpg: I prefer this, because the objects may not be *re*constructed since
they might not have been constructed in the first place. Also, ``instructions''
might never appear, only some collaboration need be implied:
COMPILE-FILE, on the other hand, must produce an output file which
when loaded with LOAD constructs the objects defined by the source
code.]
The EQL relationship is not well-defined in this case, since the
compiled file may be loaded into a different Lisp image than the one
that it was compiled in. This section defines a notion of "similarity
as constants" which relates objects in the the compile time
environment to the corresponding objects in the load time environment.
The constraints on constants described in this subsection apply only
to COMPILE-FILE; implementations are not permitted to copy or coalesce
constants appearing in code processed by EVAL or COMPILE.
Terminology
-----------
% Reference: Issue CONSTANT-COMPILABLE-TYPES
The following terminology is used in this section.
The term "constant" refers to a quoted or self-evaluating constant
or an object that is a substructure of such a constant, not a named
(DEFCONSTANT) constant. [rpg: ``self-evaluating means....'']
The term "source code" is used to refer to the objects constructed
when COMPILE-FILE calls READ, and additional objects constructed by
macroexpansion during COMPILE-FILE.
[rpg: I think the source code is whatever the representation is in
whatever a file is. I think this use of READ as a semantic crutch is
unnecessary.]
The term "compiled code" is used to refer to objects constructed by
LOAD.
[rpg: so a floating-point number constructed by LOAD is ``compiled
code''?]
The term "coalesce" is defined as follows. Suppose A and B are two
objects used as quoted constants in the source code, and that A' and
B' are the corresponding objects in the compiled code. If A' and B'
are EQL but A and B were not EQL, then we say that A and B have been
coalesced by the compiler.
[rpg: here is a first pass at changing this wording to avoid READ:
The term "coalesce" is defined as follows. Suppose A and B are two
objects defined as quoted constants in the source code, and that A'
and B' are the corresponding objects in the compiled code. If A' and
B' are EQL but A and B were not defined to be EQL, then we say that A
and B have been coalesced by the compiler.]
What may appear as a constant
-----------------------------
An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original.
The notion of "similarity as a constant" is not well-defined on all
data types. Objects of these types may not portably appear as
constants in code processed with COMPILE-FILE. Conforming
implementations are required to handle such objects either by having
the compiler and/or loader reconstruct an equivalent copy of the
object in some implementation-specific manner; or by having the
compiler signal an error.
For some aggregate data types, being similar as constants is defined
recursively. We say that an object of these types has certain "basic
attributes", and to be similar as a constant to another object, the
values of the corresponding attributes of the two objects must also be
similar as constants.
This kind of definition has problems with any circular or "infinitely
recursive" object such as a list that is an element of itself. We use
the idea of depth-limited comparison, and say that two objects are
similar as constants if they are similar at all finite levels. This
idea is implicit in the definitions below, and applies in all the
places where attributes of two objects are required to be similar as
constants.
[rpg: Hm, this comment can be got around.]
% Reference: issue CONSTANT-CIRCULAR-COMPILATION
Such circular objects may legitimately appear as constants to be
compiled. More generally, if two constants appearing in the source code
for a single file processed with COMPILE-FILE are EQL, the corresponding
constants in the compiled code must also be EQL.
% Reference: issue CONSTANT-COLLAPSING
However, the converse of this relationship need not be true; if two
objects are EQL in the compiled code, that does not always imply that
the corresponding objects in the source code were EQL. This is
because COMPILE-FILE is permitted to coalesce constants appearing in
the source code if and only if they are similar as constants, except if
the objects involved are of type SYMBOL, PACKAGE, STRUCTURE, or
STANDARD-OBJECT. Objects of these types are never coalesced.
Similarity as constants
-----------------------
Two objects are defined to be "similar as a constant" if and only if
they are both of one of the [rpg: same type from the list of] types
listed below and satisfy the additional requirements listed for that
type.
Number
Two numbers are similar as constants if they are of the same type
and represent the same mathematical value.
Character
Two characters are similar as constants if they both represent
the same character.
% Note that this definition has to depend on the results of the
% Character Set proposals. The intent is that this be compatible with
% how EQL is defined on characters.
Symbol
% Issue COMPILE-FILE-SYMBOL-HANDLING defines how the file compiler
% and loader handle interned symbols.
An uninterned symbol in the source code is similar as a constant
to an uninterned symbol in the compiled code if their print names
are similar as constants.
Package
A package in the source code is similar as a constant to a package in
the compiled code if their names are similar as constants. Note that
the loader finds the corresponding package object as if by calling
FIND-PACKAGE with the package name as an argument. An error is
signalled if no package of that name exists at load time.
Random-state
Let us say that two random-states are functionally equivalent if
applying RANDOM to them repeatedly always produces the same
pseudo-random numbers in the same order.
Two random-states are similar as constants if and only if copies of
them made via MAKE-RANDOM-STATE are functionally equivalent.
Note that a constant random-state object cannot be used as the "state"
argument to the function RANDOM (because RANDOM side-effects this
data structure).
Cons
Two conses are similar as constants if the values of their respective
CAR and CDR attributes are similar as constants.
Array
Two arrays are similar as constants if the corresponding values each
of the following attributes are similar as constants:
For 1-dimensional arrays:
LENGTH, ARRAY-ELEMENT-TYPE, and ELT for all valid indices.
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all valid indices.
In addition, if the array in the source code is a SIMPLE-ARRAY, then
the corresponding array in the compiled code must also be a
SIMPLE-ARRAY. If the array in the source code is displaced, has a
fill pointer, or is adjustable, the corresponding array in the
compiled code is permitted to lack any or all of these qualities.
[rpg: hm]
Hash Table
Two hash tables are similar as constants if they meet the following
three requirements:
(1) They both have the same test (e.g., they are both EQL hash tables).
(2) There is a unique one-to-one correspondence between the keys of
the two tables, such that the corresponding keys are similar as
constants.
(3) For all keys, the values associated with two corresponding keys
are similar as constants.
If there is more than one possible one-to-one correspondence between
the keys of the two tables, the results are unspecified. A conforming
program cannot use such a table as a constant.
[rpg: So, compilers can only be heuristic in such cases, no?]
Pathname
Two pathnames are similar as constants if all corresponding pathname
components are similar as constants.
Stream, Readtable, Method
Objects of these types are not supported in compiled constants.
Function
% Issue CONSTANT-FUNCTION-COMPILATION specifies how the compiler and
% loader handle constant functions.
Structure, Standard-object
% Reference: issue LOAD-OBJECTS
Objects of type structure and standard-object may appear in compiled
constants if there is an appropriate MAKE-LOAD-FORM method defined
for that type.
COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
a constant or as a self-evaluating form, if the object's metaclass is
STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
subclass of BUILT-IN-CLASS), or any of a possibly-empty
implementation-defined list of other metaclasses. COMPILE-FILE will
only call MAKE-LOAD-FORM once for any given object (compared with EQ)
within a single file.
Condition
% This somehow got overlooked. Are they handled under LOAD-OBJECTS?
[rpg: Yes, since they are instances of classes.]
Compile Time Error Handling
===========================
% Reference: Issue COMPILER-DIAGNOSTICS
% The STYLE-WARNING condition needs to be integrated into the section
% describing the hierarchy of condition types.
Errors and warnings may be issued within COMPILE or COMPILE-FILE.
This includes both arbitrary errors which may occur due to
compile-time processing of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) forms
or macro expansion, and conditions signalled by the compiler itself.
Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation with undefined consequences or that would cause
an error to be signalled would result at runtime.
[rpg: But this is not to be construed as an escape clause that allows
an implementation to not warn when it is required. This attempts to
only talk about how the warning is issued, right?]
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
The compiler is permitted to issue warnings about matters of
programming style as conditions of type STYLE-WARNING. Although
STYLE-WARNINGs -may- be signalled in these situations, no
implementation is -required- to do so. However, if an
implementation does choose to signal a condition, that condition
will be of type STYLE-WARNING and will be signalled by a call to
the function WARN.
Examples:
redefinition of function with different argument list
calls to function with wrong number of arguments
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
Both COMPILE and COMPILE-FILE are allowed to establish a default
condition handler. If such a condition handler is established,
however, it must first resignal the condition to give any
user-established handlers a chance to handle it. If all user error
handlers decline, the default handler may handle the condition in an
implementation-specific way; for example, it might turn errors into
warnings.
% Reference: issue WITH-COMPILATION-UNIT
In some implementations, some kinds of warnings may be deferred until
"the end of compilation"; see WITH-COMPILATION-UNIT.
-------
∂15-May-89 1710 Quinquevirate-mailer Compiler section (4.2)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 May 89 17:10:27 PDT
Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 208862; 15 May 89 20:09:34 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 595464; 15 May 89 20:11:04 EDT
Date: Mon, 15 May 89 20:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Compiler section (4.2)
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate%sail.stanford.edu@REAGAN.AI.MIT.EDU
In-Reply-To: <8905151042.AA24115@decwrl.dec.com>
Message-ID: <19890516001114.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Indented text is an excerpt from the document being discussed.
I didn't want to include the whole thing in my reply. I hope
this is enough context to locate the points I'm referrring to.
% This paragraph should really conclude with a stronger statement that
% conforming programs must be structured so they will work if implicit
% compilation does take place, but CLtL doesn't come right out and say
% that, and we have never voted on any issue to say that either.
I see no reason not to say that. I think CLtL was intended to imply it,
so I don't see any reason why the drafting committee can't decide to
say it outright. This means only a little more than that a conforming
program can't depend on just when macroexpansion takes place.
- The compiler must capture declarations to determine whether
variable bindings and references appearing lexically within the
code being compiled are to be treated as lexical or special. The
compiler must treat any binding of a variable that has not been
declared or proclaimed to be SPECIAL as a lexical binding.
- The compiler must process EVAL-WHEN forms that appear lexically within
the program being compiled. Effectively, the compiler must replace
the EVAL-WHEN form with either a PROGN containing the body forms, or
a constant NIL.
Sandra didn't like it when I pointed out that the above two points are
requirements on both the interpreter and the compiler (as of the latest
compiler issues, in the case of EVAL-WHEN) and therefore don't belong
in this section. If 4.1 is the semantics of execution of programs in
general, while 4.2 is the things that are peculiar to compilation,
then they belong in 4.1.
She didn't like it, but didn't convince me I was wrong.
[rpg: There is a complicated issue: Can the compiler assume that the
resulting code in a compile-file situation will be run in the same
Lisp? The same implementation? The same computer? The same type of
computer?
I suggest that we say that the semantics we discuss presumes that the
compiler can assume that when doing compile-file that the resulting
code will be loaded into a fresh copy of the same Lisp.]
I think that is reasonable. Implementations of compile-file can work in
other cases too, if they feel like it, but this is the only case
specified by the standard. I think trying to define precisely what
"the same" means is likely to run into problems, I'd suggest leaving it
with rpg's wording and not trying to be more precise.
However we have to be careful not to rule out the common technique of
compiling a multifile program by compiling the first file, loading the
result, compiling the second file, loading it, etc. It would be a shame
if conformance required rebooting the Lisp between each compilation.
[rpg: the interpreter can assume the same thing, right?
ANYTHING the compiler can assume the interpreter can also assume, since
there is nothing in Common Lisp that mandates any semantic differences
between the compiler and the interpreter. Some implementations only
have one or the other.
- COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at run time.
[rpg: the interpreter can assume the same thing, right?]
I don't think so, or even known what it would mean, because this is a
statement about COMPILE-FILE, not about the compiler. Maybe LOAD of
a source file may assume ....?
[rpg: This is a little curious. Is this talking only about this sort of case:....
Well, this whole section is unclear when it talks about the compile time
environment as to whether it means definitions made in the file being
compiled or definitions made in the Lisp running the compiler, either
before calling COMPILE-FILE or inside EVAL-WHEN COMPILE in the file.
I think it means both. Of course these things when they say "the compiler"
rather than "COMPILE-FILE" also are talking about the COMPILE function
and implicit compilation, for which the compile time environment and the
run time environment are two different states of the same Lisp at different
times. Maybe Sandra should clarify?
* If the form is an EVAL-WHEN form, it is handled according to
the following table:
The formatting of this table is completely destroyed, the headings do
not line up with the columns. To get a narrow enough table, maybe the
columns will have to be labelled with numbers and the headings given
in a caption.
[rpg: I prefer this, because the objects may not be *re*constructed since
they might not have been constructed in the first place. Also, ``instructions''
might never appear, only some collaboration need be implied:
COMPILE-FILE, on the other hand, must produce an output file which
when loaded with LOAD constructs the objects defined by the source
code.]
I prefer this also. The only problem is that the objects aren't always
actually constructed, sometimes they already exist and are just referenced.
It's not clear that fixing that would improve understandability, so leave it.
However, it mandates some rewording of the next paragraph since it is no
longer clear what EQL relationship is being referred to. I offer:
In the case of COMPILE-FILE, we cannot speak of objects constructed by
LOAD of the output file being EQL to objects constructed at compile
time, since the compiled file may be loaded into a different Lisp image
than the one that it was compiled in. This section defines a notion of
"similarity as constants" which relates objects in the the compile time
environment to the corresponding objects in the load time environment.
% Issue COMPILE-FILE-SYMBOL-HANDLING defines how the file compiler
% and loader handle interned symbols.
This sentence can't be commented out without replacing it with something.
Commenting it out leaves the discussion of symbols incomplete.
Two arrays are similar as constants if the corresponding values each
of each
For arrays of other dimensions:
other rank
I read through to the end but have no other comments right now.
I might comment on the next revision though.
∂16-May-89 0548 Quinquevirate-mailer conformance
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 16 May 89 05:48:01 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA28475; Tue, 16 May 89 05:48:56 PDT
Message-Id: <8905161248.AA28475@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA28475; Tue, 16 May 89 05:48:56 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 16 May 89 08:24
To: quinquevirate@sail.stanford.edu
Subject: conformance
Since this issue will map directly into section 1.5 of the standard, I thought
you might want to review it before I send it to X3J13. I'll be sending it
out next Monday.
kathy
Issue: CONFORMANCE-POSITION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
10-JAN-89, Version 4 by Chapman
6-FEB-89, Version 5 by Chapman
20-FEB-89, Version 6 by Chapman
5-MAY-89, Version 7 by Chapman
Problem Description:
Two ways of defining conformance are in terms of conforming code
and in terms of a conforming implementation. How should our standard
define conformance? What is the relationship between conformance and
portability?
Proposal (CONFORMANCE-POSITION:IMPLEMENTATION-AND-CODE)
The standard presents the syntax and semantics to be implemented by
a conforming implementation. In addition, it levies requirements on
conforming code and documentation.
Definitions:
Code: One or more Common Lisp forms meant to be evaluated.
Processor: A system or mechanism that accepts code as input, prepares
it for execution, and executes the process so defined with data to produce
results.
Implementation-dependent: Possibly differing between processors and not
necessarily defined for any particular processor.
Implementation-defined: Possibly differing between processors, but defined
for any particular processor.
Extension: A facility in the implemented language that is not given in this
standard but that does not cause any ambiguity or contradiction when added
to the language standard.
Conformance:
A processor conforming with the requirements of this standard shall:
1. accept all the features of the language specified in this standard,
with the meanings defined in this standard.
2. not require the inclusion of substitute or additional language elements in
code in order to accomplish a feature of the language that is specified
in this standard.
3. be accompanied by a document that provides a definition of all
implementation-defined features.
4. treat exceptional situations in the manner specified in section 1.4 of
the standard (i.e. the Definitions section. It contains the error terminology.).
5. be accompanied by a document that separately describes any features accepted
by the processor that are prohibited or not specified in this standard.
Such extensions shall be described as being ``extensions to Common Lisp
as specified by ANSI ...''.
6. produce a conformance statement as a consequence of using the processor,
or that statement shall be included in the accompanying documentation.
If the processor conforms in all respects with this standard, the conformance
statement shall be
``<This processor> conforms with the requirements of ANSI <standard number>''
If the processor conforms with some but not all of the requirements of this
standard, then the conformance statement shall be
``<This processor> conforms with the requirements of ANSI <standard number>
with the following exceptions:
<followed by a reference to, or a complete list of, the requirements of
the standard with which the processor does not conform>.
Code conforming with the requirements of this standard shall:
1. use only those features of the language specified in this standard.
2. not rely on any particular interpretation of implementation-dependent
features.
Note that code that conforms with the requirements of this standard
may rely on particular implementation-defined values or features. Also note
that the requirements for conforming code and conforming processors do
not require that the results produced by conforming code are always
the same when processed by a conforming processor. They may be, or they may
differ, depending on the code.
Informally, the basic rules for conformance are as follows:
1. Conforming code uses only the syntax specified in the standard.
2. Conforming code is written in only the sequence specified in the standard.
3. Conforming code is written using only the functions, macros,
special forms, variables, and constants specified in the standard.
4. Conforming implementations provide the functions, macros, special
forms, variables, and constants specified in the standard,
and arrange that they behave in ways
that conform to the specifications of them in the standard.
The definitions of all other functions, macros, or symbols must accompany
the code. Extensions to syntax are not allowed in conforming code.
5. Conformance will not be machine-checkable.
6. Conforming code will only be defined in terms of its structure.
It's possible for a conformal code to
run in all conformal implementations, but to have allowable
implementation-defined behavior that could make it non-portable.
Insofar as we allow options in the standard this will be true.
Portable code is required to produce equivalent results and
observable side effects in all conforming implementations.
Portable code is written using only STANDARD-CHAR-P characters.
Portable code is written using no extra optional keyword arguments.
Rationale:
The standard must contain information about conformance. Only including
requirements that would be placed on implementations, however, leaves
the possibility open that something would be overlooked, and so
implementations may well conform without processing correctly
conforming code.
Current Practice:
CLtL generally describes things in terms of what correct code can
expect, but the document itself levies the requirement on an implementation
to support all the described functionality.
dpANS C also defined conformance in terms of code.
It has further defined both "conforming" and "strictly conforming" code.
Pascal defines conformance in terms of both, PL/I defines conformance in
terms of conforming code only.
Fortran and Ada say that a conforming implementation correctly processes
conforming code. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both code and implementations.
Adoption Cost:
The use of the words "implementation-defined" and "implementation-dependent"
in CLtL and the standard will have to be checked to make sure the uses
and the definitions given above coincide. Any changes that occur as a
result of this check could potentially affect some user code, but it's
unlikely.
Implementations will have to be checked to make sure they conform with the
rules stated above, and conformance statements will have to be added.
Documentation may have to be updated.
Benefits:
This definition will give readers and validators a basis on which to read
the standard.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
The information in this issue was derived from three documents:
the C ANSI standard, the "Proposed Draft Techinical Report-Guidelines on the
preparation of conformity clauses in porogramming languages and Letter Ballot"
(CT22/87-094, ISO/TC97/SC22/WG12 N133 Rev 1, October, 1987), and
"Specification for Computer programming language Pascal" (BS 6192:1982,
UDC 681.3.06 Pascal: 519.682).
∂16-May-89 0748 Quinquevirate-mailer re: Compiler section (4.2)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 May 89 07:48:07 PDT
Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 209082; 16 May 89 10:47:04 EDT
Message-ID: <a#VeG@SAIL.Stanford.EDU>
Date: 16 May 89 0746 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: re: Compiler section (4.2)
To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM
CC: quinquevirate%sail.stanford.edu@REAGAN.AI.MIT.EDU
[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Mon, 15 May 89 20:11 EDT.]
Moon writes:
``I don't think so, or even known what it would mean, because this is a
statement about COMPILE-FILE, not about the compiler. Maybe LOAD of
a source file may assume ....?''
[rpg: I'm imagining an implementation strategy in which a separate image
with a compiler compile-file's all input to the ``real Lisp'' and the real
Lisp loads it. You can also imagine that the ``real Lisp'' is clever to
batch up forms to be compiled to the compiler image, making the analogy
to a file more precise. Possibly this is stretching the point. (Also, the
collaboration between these two processes must be tight to provide the
right behavior according to what COMPILE must do.]
Moon writes:
``I prefer this also. The only problem is that the objects aren't always
actually constructed, sometimes they already exist and are just referenced.
It's not clear that fixing that would improve understandability, so leave it.''
[rpg: Quite right. How about this:
COMPILE-FILE, on the other hand, must produce an output file which when
loaded with LOAD constructs or references or both the objects defined by
the source code.]
∂16-May-89 1035 Quinquevirate-mailer conformance
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 May 89 10:35:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 595810; 16 May 89 13:21:04 EDT
Date: Tue, 16 May 89 13:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: conformance
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate@SAIL.STANFORD.EDU
In-Reply-To: <8905161248.AA28475@decwrl.dec.com>
Message-ID: <19890516172114.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'm not a conformance expert, but this seems basically okay to me.
I just have a couple of criticisms. Indented text is excerpted from
your message.
Extensions to syntax are not allowed in conforming code.
This is ambiguous. It could be read to mean that conforming code is not
permitted to define reader macros. However, what I think you meant is
that conforming code is not permitted to depend on
implementation-provided syntax extensions. Is that what you meant?
How is that different from:
1. Conforming code uses only the syntax specified in the standard.
In fact, that statement might also be read to rule out definition of
reader macros by conforming code. You should treat syntax the same
as functions, macros, etc., i.e. conforming code must use only the
things defined in the standard plus things whose definition accompanies
the program, where "things" includes syntax as well as defined names.
6. Conforming code will only be defined in terms of its structure.
as contrasted with what? Its behavior? Say explicitly.
Perhaps the whole "informal rules" section needs a little more writing
to use more parallel constructions and avoid ambiguities and loopholes.
Even though it's informal it should not be ambiguous.
Portable code is required to produce equivalent results and
observable side effects in all conforming implementations.
Portable code is written using only STANDARD-CHAR-P characters.
Portable code is written using no extra optional keyword arguments.
The term "portable" is never defined. Is this a definition? (In which
case move it to the definitions section earlier in the proposal.) If this
is not a definition, but a restriction on something whose definition is
different, add an explicit definition. Also I don't understand what the
last sentence about "extra optional keyword arguments" is supposed to
refer to, nor how portable and conforming code differ in this respect.
Rationale:
The standard must contain information about conformance. Only including
requirements that would be placed on implementations, however, leaves
the possibility open that something would be overlooked, and so
implementations may well conform without processing correctly
conforming code.
Sorry, I couldn't understand the second sentence at all. I couldn't
even parse it.
∂16-May-89 1036 Quinquevirate-mailer re: Compiler section (4.2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 May 89 10:35:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 595794; 16 May 89 12:47:49 EDT
Date: Tue, 16 May 89 12:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: re: Compiler section (4.2)
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: quinquevirate@SAIL.STANFORD.EDU
In-Reply-To: <a#VeG@SAIL.Stanford.EDU>
Message-ID: <19890516164758.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 16 May 89 0746 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
- COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at run time.
[rpg: the interpreter can assume the same thing, right?]
Moon writes:
``I don't think so, or even known what it would mean, because this is a
statement about COMPILE-FILE, not about the compiler. Maybe LOAD of
a source file may assume ....?''
[rpg: I'm imagining an implementation strategy in which a separate image
with a compiler compile-file's all input to the ``real Lisp'' and the real
Lisp loads it. You can also imagine that the ``real Lisp'' is clever to
batch up forms to be compiled to the compiler image, making the analogy
to a file more precise. Possibly this is stretching the point. (Also, the
collaboration between these two processes must be tight to provide the
right behavior according to what COMPILE must do.]
I don't think an analogy to a file is good enough if we're going to give
files such prominence that block compilation within one file is allowed but
across files is not allowed, which is my interpretation of what Sandra's
text quoted above says. I think I'd be happiest if we just left this part
referring to COMPILE-FILE as written. The implementation strategy you're
imagining might have to disable block compilation when compiling things
sent over from the Lisp, but I see no harm in that.
Moon writes:
``I prefer this also. The only problem is that the objects aren't always
actually constructed, sometimes they already exist and are just referenced.
It's not clear that fixing that would improve understandability, so leave it.''
[rpg: Quite right. How about this:
COMPILE-FILE, on the other hand, must produce an output file which when
loaded with LOAD constructs or references or both the objects defined by
the source code.]
Good. (I'd use "and/or" to avoid saying "or both"; either way is okay.)
∂16-May-89 1110 Quinquevirate-mailer re: Compiler section (4.2)
To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM
CC: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message sent Tue, 16 May 89 12:47 EDT.]
``...block compilation within one file is allowed but
across files is not allowed, which is my interpretation of what Sandra's
text quoted above says.''
Seems that block compilation should be on a compilation-unit
basis, don't you think? We can leave the original text as is.
I was using ``or both'' to avoid saying ``and/or''. I don't care
either.
-rpg-
∂16-May-89 1113 Quinquevirate-mailer re: Compiler section (4.2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 May 89 11:13:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 595846; 16 May 89 14:13:27 EDT
Date: Tue, 16 May 89 14:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: re: Compiler section (4.2)
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: quinquevirate@SAIL.STANFORD.EDU
In-Reply-To: <m#Ydr@SAIL.Stanford.EDU>
Message-ID: <19890516181340.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 16 May 89 1110 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Seems that block compilation should be on a compilation-unit
basis, don't you think?
That's what I wanted WITH-COMPILATION-UNIT to be, but I couldn't
find anybody to agree with me.
∂16-May-89 1133 Quinquevirate-mailer Compiler section (4.2)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 16 May 89 11:33:51 PDT
Received: from fafnir.think.com by Think.COM; Tue, 16 May 89 14:33:26 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 16 May 89 14:33:16 EDT
Received: from joplin.think.com by verdi.think.com; Tue, 16 May 89 14:33:03 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Tue, 16 May 89 14:33:00 EDT
Date: Tue, 16 May 89 14:33:00 EDT
Message-Id: <8905161833.AA00368@joplin.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: RPG@sail.stanford.edu, quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 16 May 89 12:47 EDT <19890516164758.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Compiler section (4.2)
[rpg: Quite right. How about this:
COMPILE-FILE, on the other hand, must produce an output file which when
loaded with LOAD constructs or references or both the objects defined by
the source code.]
Good. (I'd use "and/or" to avoid saying "or both"; either way is okay.)
Maybe he meant "constructs or references or boths the objects".
∂16-May-89 1138 Quinquevirate-mailer Compiler section (4.2)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 16 May 89 11:38:01 PDT
Received: from fafnir.think.com by Think.COM; Tue, 16 May 89 14:37:27 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 16 May 89 14:37:16 EDT
Received: from joplin.think.com by verdi.think.com; Tue, 16 May 89 14:37:04 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Tue, 16 May 89 14:37:02 EDT
Date: Tue, 16 May 89 14:37:02 EDT
Message-Id: <8905161837.AA00373@joplin.think.com>
To: RPG@sail.stanford.edu
Cc: Moon@stony-brook.scrc.symbolics.com, quinquevirate@sail.stanford.edu
In-Reply-To: Dick Gabriel's message of 16 May 89 1110 PDT <m#Ydr@SAIL.Stanford.EDU>
Subject: Compiler section (4.2)
I was using ``or both'' to avoid saying ``and/or''. I don't care
either.
Since nobody seems to care, I can safely summarize the result as:
Use both or and/or or both.
∂16-May-89 1457 Quinquevirate-mailer checked out status (5/16)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 16 May 89 14:57:15 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14122; Tue, 16 May 89 14:58:14 PDT
Message-Id: <8905162158.AA14122@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA14122; Tue, 16 May 89 14:58:14 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 16 May 89 15:49
To: quinquevirate@sail.stanford.edu
Subject: checked out status (5/16)
Section Who has Date out Status
1.1 KC Done
1.2 KC
1.3 KC
1.4 KC
1.5 KC
1.6 KC
2.1 KC
2.2 Moon 5/5/89 Second iteration
2.3 RPG 5/5/89
2.4 RPG 5/5/89
2.5 RPG 5/5/89
3.1 Masinter 5/5/89
3.2 Masinter 5/5/89
3.3 Masinter 5/5/89
3.4 Masinter 5/5/89
4.1 Moon 5/5/89 Second iteration
4.2 RPG 5/16/89 Reviewing Sandra's document
5.1 RPG 4/7/89
5.2 Masinter 4/7/89
5.3 Masinter 4/7/89
5.4 Masinter 4/7/89
6.1 RPG 5/5/89
Glossary RPG 5/16/89 Extensive KMP review
CLOS RPG 5/2/89
PREDICATES Masinter 5/3/89
STRINGS Masinter 5/3/89
SEQUENCES Masinter 5/3/89
LISTS Masinter 5/3/89
NUMBERS Masinter 5/3/89
STRUCTURES GLS 5/3/89
SYMBOLS GLS 5/3/89
HASHTABLES GLS 5/3/89
ARRAYS GLS 5/3/89
TYPES GLS 5/3/89
DECLARATIONS GLS 5/3/89
IO KC
STREAMS KC
FILE KC
CONTROL KC
PROGRAM KC
MISC KC
ERRORS Moon 5/4/89
MACROS Moon 5/4/89
PACKAGES Moon 5/4/89
CHARACTERS Moon 5/4/89
EVALUATOR Moon 5/4/89
∂18-May-89 1304 Quinquevirate-mailer checked out as of 5/18
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 May 89 13:04:53 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA01264; Thu, 18 May 89 13:05:49 PDT
Message-Id: <8905182005.AA01264@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA01264; Thu, 18 May 89 13:05:49 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 May 89 15:52
To: quinquevirate@sail.stanford.edu
Subject: checked out as of 5/18
Section Who has Date out Status
1.1 KC Done
1.2 KC Updating as necessary
1.3 KC Updating as necessary
1.4 KC Updating as necessary
1.5 KC Updating as necessary
1.6 KC Updating as necessary
2.1 KC Updating as necessary
2.2 Moon 5/5/89 Second iteration
2.3 RPG 5/5/89 Reviewing?
2.4 RPG 5/5/89 Reviewing?
2.5 RPG 5/5/89 Reviewing?
3.1 Moon 5/5/89 First review
3.2 Moon 5/5/89 First review
3.3 Moon 5/5/89 First review
3.4 Moon 5/5/89 First review
4.1 Moon 5/5/89 Second iteration
4.2 RPG 5/16/89 Reviewing Sandra's document
5.1 RPG 4/7/89 Rewriting?
5.2 Masinter 4/7/89 Reviewing?
5.3 Masinter 4/7/89 Reviewing?
5.4 KC Masinter is to review
6.1 RPG 5/5/89 Reviewing?
Glossary RPG 5/16/89 Extensive KMP + Moon review
For all of the following "sections" that KC has,
comments from other reviewers are being inserted, but they can
be made available to the person who is to review them anytime.
Also, if you are not reviewing the parts checked out to you, you
can check them back in and I can include the compiler and character
issues in those sections.
CLOS RPG 5/2/89 Reviewing?
PREDICATES KC Masinter is to review
STRINGS KC Masinter is to review
SEQUENCES KC Masinter is to review
LISTS KC Masinter is to review
NUMBERS KC Masinter is to review
STRUCTURES GLS 5/3/89
SYMBOLS GLS 5/3/89
HASHTABLES GLS 5/3/89
ARRAYS GLS 5/3/89
TYPES GLS 5/3/89
DECLARATIONS GLS 5/3/89
IO KC Masinter is to review
STREAMS KC Masinter is to review
FILE KC Masinter is to review
CONTROL KC Masinter is to review
PROGRAM KC Masinter is to review
MISC KC Masinter is to review
ERRORS Moon 5/4/89
MACROS Moon 5/4/89 First review
PACKAGES Moon 5/4/89
CHARACTERS Moon 5/4/89
EVALUATOR Moon 5/4/89
∂22-May-89 1248 Quinquevirate-mailer Sections 2.3 and 2.5
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 22 May 89 12:46:43 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 598838; 22 May 89 15:38:21 EDT
Date: Mon, 22 May 89 15:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Sections 2.3 and 2.5
To: Richard P. Gabriel <rpg@lucid.com>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8904221836.AA01737@challenger>
Message-ID: <19890522194239.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Sat, 22 Apr 89 11:36:27 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Of the three approaches Moon suggests, I favor a combination of
bringing some stuff into the main specification from the prototype
chapter 3 and flagging the rest as places for future extension.
This conversation seems to have flagged. Out of inertia, I favor
minimizing changes to the language rather than trying to bring in
parts of chapter 3, even though if we did the extra work to rethink
the boundary between chapter 2 and chapter 3 we would probably end
up with a better language.
I feel that the largest exposures we have are readers (but not
writers) for some things like these (this list suggested by Jonl):
class-direct-supers, class-direct-subclasses, class-direct-slots,
class-slots, class-direct-methods, class-precedence-list,
class-forward-referenced-supers, class-no-of-instance-slots,
method-function, method-generic-function, method-arglist,
method-qualifiers, method-specializers, generic-function-name,
generic-function-methods, generic-function-discriminator-code,
generic-function-lambda-list, slotd-name, slotd-allocation,
slotd-initform, slotd-initargs, and slotd-type.
method-qualifiers is already in chapter 2. The slotd- ones would
require also bringing slotd objects in chapter 2 (currently they
aren't), which I'm afraid of because the chapter 3 definition of slotd
objects seems to still be changing. The ones that return lists of slotd
objects can't be used if we don't have slotd objects.
class-forward-referenced-supers is too controversial as well as a bad
name. class-no-of-instance-slots seems unnecessary and is a bad name.
generic-function-discriminator-code is too implementation-dependent.
method-function is too implementation-dependent.
The remaining ones would be okay, however I haven't found the time to
figure out whether they would make a complete and consistent set.
That's class-direct-supers [again a bad name], class-direct-subclasses,
class-direct-methods, class-precedence-list, method-generic-function,
method-arglist [should be method-lambda-list], method-specializers,
generic-function-name, generic-function-methods, and
generic-function-lambda-list.
Also we are exposed on the inability to make methods for add-method to
use. These are the places where I would consider trying move something
into the main specification.
I agree about the add-method problem. Since the macroexpansion of defmethod
in chapter 3 is still in flux, I think it might be unwise to try to bring
into chapter 2 a way to construct the argument to add-method. It might be
better to get rid of add-method. I haven't found the time to figure out
whether getting rid of add-method would break anything. Maybe it's better
just to flag add-method as a place for future expansion and not change
the language.
I looked through the summary on pages 2-5 and 2-6 of 88-002R and the following
seemed not clearly justified as chapter 2 rather than chapter 3. Again I
can't claim to have evaluated the possible danger of kicking these out to
chapter 3.
add-method
compute-applicable-methods
ensure-generic-function
Everything else in chapter 2 clearly belongs in the programmer interface
rather than the metaobjects level.
Also it's perhaps time to bring up the question of whether we really want
the ANSI standard to include generic-flet, generic-function, generic-labels,
and with-added-methods. While these nicely round out the language, I have
so far been unable to discover any CLOS implementation that implements them
or says it plans to implement them. Putting them in the standard is
probably premature in the absence of any practice.
Someone [probably KMP] writes:
``p.2-3, para.3: Without meta objects one can't create anonymous
classes and improper class names, so much of this paragraph is
currently irrelevant. Keep the first two sentences and the last
sentence, delete the rest. [I think we should keep it anyway, but
flag it as a framework for future extensions --Moon]''
Hm, I thought CLASS-NAME was a SETFable place, as was FIND-CLASS, but
I guess that isn't true as it currently stands.
class-name and find-class are both documented as setf'able in 88-002R.
There's no way to make an argument for (setf find-class) except by
getting a named class defined by defclass, but still this is enough to
create improper class names and even anonymous classes in a roundabout
way. So most likely the whole paragraph should be kept (I don't have
a copy of it here to recheck what it said).
``p.2-4, para.3,4: Again the stuff about metaclasses is not relevant to
the current metaobject-free standard.''
Well, there are various metaclasses now (structure-class and
standard-class), and there are some places that talk about compatible
metaclasses. I can't believe it's reasonable to flush all mention of
metaclasses because you cannot create them. (Actually, you can, but it
isn't likely that you can do anything useful with them. For example,
you can do (defclass random-metaclass (standard-class)) and then
proceed to make instances of it which are hardly distinguishable from
ordinary standard classes.)
Agreed.
``p.2-5, bullet 3: changing "is shared by instances" to
"is shared by all instances" would be clearer.''
This is fine. Kathy, can you do this?
Agreed.
``p.2-5: Delete the 3-line inheritance section. This section has been
reorganized into nonexistence.
p.2-5: Inheritance of Class Options should come after the class
precedence list section.''
Ok. Kathy, can you do this?
``p.2-9, Redefining Classes, Third paragraph: The CLOS spec says when
slots aren't updated, X3J13 says when they are updated. X3J13 doesn't
mention anything about changes to ordering. [How come this spec.
doesn't say exactly the same thing as 88-002R here? --Moon]''
I don't quite get this. I have the Feb 14 X3J13 draft here (my March 21
draft is at work), and both the Feb 14 draft and 88-002R say this:
``Note that redefining a class may cause slots to be added or deleted.
If a class is redefined in a way that changes the set of local slots
accessible in instances, the instances will be updated. It is
implementation dependent whether instances are updated if a class is
redefined in a way that does not change the set of local slots
accessible in instances.''
On the other hand, this paragraph appears on page 2-47 not 2-9, so it's
hard to tell whether we are all talking about the same thing.
I don't have the thing here, but I think we're not al talking about the same
thing and on p.2-9 there was some text that needs to be made consistent
with the other parts of the document.
``In several of these paragraphs, references are made to the "old class"
and the "new class". It would be clearer to say "the old class
definition" and "the new class definition" since it's still the same
class object after the redefinition.''
I think there is ample distinction made in the first paragraph of this section
between the class object and the class. This section and others like it
are difficult enough to understand without extra words like ``definition''
being thrown in where that doesn't really aid understanding. Consider how
you would rewrite this using ``definition'':
``The value of a slot that is specified as shared both in the old class
and in the new class is retained. If such a shared slot was unbound
in the old class, it will be unbound in the new class. Slots that
were local in the old class and that are shared in the new class are
initialized. Newly added shared slots are initialized.''
Here is a try:
``The value of a slot that is specified as shared both by the old
class definition and by the new class definition is retained. If such
a shared slot was unbound in the class specified by the old
definition, it will be unbound in the class specified by the new
definition. Slots that were specified as local by the old class
definition and that are specified as shared by the new class are
initialized. Newly added shared slots are initialized.''
I'm not sure that this slightly more precise paragraph says anything
more than the original, and it is a lot harder to understand.
It just seems longer to me, and not harder to understand for any
reason other than the extra length. However I really have no
opinion on this issue. BTW I was unaware that there was _any_
distinction between "the class object" and "the class."
Finally, the classes might be EQ, but they are not equal as classes.
(1 2 3) and (a b c d e) might be EQ, but one is the old list and the
other is the new list, if one was derived from the other via
replacement.
Well, as soon as time-varying objects are brought into the picture,
equality becomes ten times as hard to talk about.
∂22-May-89 1248 Quinquevirate-mailer Sections 2.3 and 2.5
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 22 May 89 12:46:43 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 598839; 22 May 89 15:39:14 EDT
Date: Mon, 22 May 89 15:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Sections 2.3 and 2.5
To: Richard P. Gabriel <rpg@lucid.com>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8904221836.AA01737@challenger>
Supersedes: <19890522194239.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Comments: Remove my misattribution of some comments to KMP
Message-ID: <19890522194337.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Sat, 22 Apr 89 11:36:27 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Of the three approaches Moon suggests, I favor a combination of
bringing some stuff into the main specification from the prototype
chapter 3 and flagging the rest as places for future extension.
This conversation seems to have flagged. Out of inertia, I favor
minimizing changes to the language rather than trying to bring in
parts of chapter 3, even though if we did the extra work to rethink
the boundary between chapter 2 and chapter 3 we would probably end
up with a better language.
I feel that the largest exposures we have are readers (but not
writers) for some things like these (this list suggested by Jonl):
class-direct-supers, class-direct-subclasses, class-direct-slots,
class-slots, class-direct-methods, class-precedence-list,
class-forward-referenced-supers, class-no-of-instance-slots,
method-function, method-generic-function, method-arglist,
method-qualifiers, method-specializers, generic-function-name,
generic-function-methods, generic-function-discriminator-code,
generic-function-lambda-list, slotd-name, slotd-allocation,
slotd-initform, slotd-initargs, and slotd-type.
method-qualifiers is already in chapter 2. The slotd- ones would
require also bringing slotd objects in chapter 2 (currently they
aren't), which I'm afraid of because the chapter 3 definition of slotd
objects seems to still be changing. The ones that return lists of slotd
objects can't be used if we don't have slotd objects.
class-forward-referenced-supers is too controversial as well as a bad
name. class-no-of-instance-slots seems unnecessary and is a bad name.
generic-function-discriminator-code is too implementation-dependent.
method-function is too implementation-dependent.
The remaining ones would be okay, however I haven't found the time to
figure out whether they would make a complete and consistent set.
That's class-direct-supers [again a bad name], class-direct-subclasses,
class-direct-methods, class-precedence-list, method-generic-function,
method-arglist [should be method-lambda-list], method-specializers,
generic-function-name, generic-function-methods, and
generic-function-lambda-list.
Also we are exposed on the inability to make methods for add-method to
use. These are the places where I would consider trying move something
into the main specification.
I agree about the add-method problem. Since the macroexpansion of defmethod
in chapter 3 is still in flux, I think it might be unwise to try to bring
into chapter 2 a way to construct the argument to add-method. It might be
better to get rid of add-method. I haven't found the time to figure out
whether getting rid of add-method would break anything. Maybe it's better
just to flag add-method as a place for future expansion and not change
the language.
I looked through the summary on pages 2-5 and 2-6 of 88-002R and the following
seemed not clearly justified as chapter 2 rather than chapter 3. Again I
can't claim to have evaluated the possible danger of kicking these out to
chapter 3.
add-method
compute-applicable-methods
ensure-generic-function
Everything else in chapter 2 clearly belongs in the programmer interface
rather than the metaobjects level.
Also it's perhaps time to bring up the question of whether we really want
the ANSI standard to include generic-flet, generic-function, generic-labels,
and with-added-methods. While these nicely round out the language, I have
so far been unable to discover any CLOS implementation that implements them
or says it plans to implement them. Putting them in the standard is
probably premature in the absence of any practice.
Someone writes:
[it wasn't KMP]
``p.2-3, para.3: Without meta objects one can't create anonymous
classes and improper class names, so much of this paragraph is
currently irrelevant. Keep the first two sentences and the last
sentence, delete the rest. [I think we should keep it anyway, but
flag it as a framework for future extensions --Moon]''
Hm, I thought CLASS-NAME was a SETFable place, as was FIND-CLASS, but
I guess that isn't true as it currently stands.
class-name and find-class are both documented as setf'able in 88-002R.
There's no way to make an argument for (setf find-class) except by
getting a named class defined by defclass, but still this is enough to
create improper class names and even anonymous classes in a roundabout
way. So most likely the whole paragraph should be kept (I don't have
a copy of it here to recheck what it said).
``p.2-4, para.3,4: Again the stuff about metaclasses is not relevant to
the current metaobject-free standard.''
Well, there are various metaclasses now (structure-class and
standard-class), and there are some places that talk about compatible
metaclasses. I can't believe it's reasonable to flush all mention of
metaclasses because you cannot create them. (Actually, you can, but it
isn't likely that you can do anything useful with them. For example,
you can do (defclass random-metaclass (standard-class)) and then
proceed to make instances of it which are hardly distinguishable from
ordinary standard classes.)
Agreed.
``p.2-5, bullet 3: changing "is shared by instances" to
"is shared by all instances" would be clearer.''
This is fine. Kathy, can you do this?
Agreed.
``p.2-5: Delete the 3-line inheritance section. This section has been
reorganized into nonexistence.
p.2-5: Inheritance of Class Options should come after the class
precedence list section.''
Ok. Kathy, can you do this?
``p.2-9, Redefining Classes, Third paragraph: The CLOS spec says when
slots aren't updated, X3J13 says when they are updated. X3J13 doesn't
mention anything about changes to ordering. [How come this spec.
doesn't say exactly the same thing as 88-002R here? --Moon]''
I don't quite get this. I have the Feb 14 X3J13 draft here (my March 21
draft is at work), and both the Feb 14 draft and 88-002R say this:
``Note that redefining a class may cause slots to be added or deleted.
If a class is redefined in a way that changes the set of local slots
accessible in instances, the instances will be updated. It is
implementation dependent whether instances are updated if a class is
redefined in a way that does not change the set of local slots
accessible in instances.''
On the other hand, this paragraph appears on page 2-47 not 2-9, so it's
hard to tell whether we are all talking about the same thing.
I don't have the thing here, but I think we're not al talking about the same
thing and on p.2-9 there was some text that needs to be made consistent
with the other parts of the document.
``In several of these paragraphs, references are made to the "old class"
and the "new class". It would be clearer to say "the old class
definition" and "the new class definition" since it's still the same
class object after the redefinition.''
I think there is ample distinction made in the first paragraph of this section
between the class object and the class. This section and others like it
are difficult enough to understand without extra words like ``definition''
being thrown in where that doesn't really aid understanding. Consider how
you would rewrite this using ``definition'':
``The value of a slot that is specified as shared both in the old class
and in the new class is retained. If such a shared slot was unbound
in the old class, it will be unbound in the new class. Slots that
were local in the old class and that are shared in the new class are
initialized. Newly added shared slots are initialized.''
Here is a try:
``The value of a slot that is specified as shared both by the old
class definition and by the new class definition is retained. If such
a shared slot was unbound in the class specified by the old
definition, it will be unbound in the class specified by the new
definition. Slots that were specified as local by the old class
definition and that are specified as shared by the new class are
initialized. Newly added shared slots are initialized.''
I'm not sure that this slightly more precise paragraph says anything
more than the original, and it is a lot harder to understand.
It just seems longer to me, and not harder to understand for any
reason other than the extra length. However I really have no
opinion on this issue. BTW I was unaware that there was _any_
distinction between "the class object" and "the class."
Finally, the classes might be EQ, but they are not equal as classes.
(1 2 3) and (a b c d e) might be EQ, but one is the old list and the
other is the new list, if one was derived from the other via
replacement.
Well, as soon as time-varying objects are brought into the picture,
equality becomes ten times as hard to talk about.
∂22-May-89 1416 Quinquevirate-mailer checked out as of 5/22
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 22 May 89 14:16:44 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA23492; Mon, 22 May 89 14:17:48 PDT
Message-Id: <8905222117.AA23492@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA23492; Mon, 22 May 89 14:17:48 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 22 May 89 17:11
To: quinquevirate@sail.stanford.edu
Subject: checked out as of 5/22
Section Who has Date out Status
1.1 KC Done
1.2 KC Updating as necessary
1.3 KC Updating as necessary
1.4 KC Updating as necessary
1.5 KC Updating as necessary
1.6 KC Updating as necessary
2.1 KC Updating as necessary
2.2 KC Done
2.3 RPG 5/5/89 Reviewing?
2.4 RPG 5/5/89 Reviewing?
2.5 RPG 5/5/89 Reviewing?
3.1 KC Moon/Masinter to review
3.2 KC Moon/Masinter to review
3.3 KC Moon/Masinter to review
3.4 KC Moon/Masinter to review
4.1 Moon 5/5/89 Second iteration
4.2 RPG 5/16/89 Reviewing Sandra's document
5.1 RPG 4/7/89 Rewriting?
5.2 Masinter 4/7/89 Reviewing?
5.3 Masinter 4/7/89 Reviewing?
5.4 KC Masinter is to review
6.1 RPG 5/5/89 Reviewing?
Glossary RPG 5/16/89 Extensive KMP + Moon review
For all of the following "sections" that KC has,
comments from other reviewers are being inserted, but they can
be made available to the person who is to review them anytime.
Also, if you are not reviewing the parts checked out to you, you
can check them back in and I can include the compiler and character
issues in those sections.
CLOS RPG 5/2/89 Reviewing?
PREDICATES KC Masinter is to review
STRINGS KC Masinter is to review
SEQUENCES KC Masinter is to review
LISTS KC Masinter is to review
NUMBERS KC Masinter is to review
STRUCTURES GLS 5/3/89
SYMBOLS GLS 5/3/89
HASHTABLES GLS 5/3/89
ARRAYS GLS 5/3/89
TYPES GLS 5/3/89
DECLARATIONS GLS 5/3/89
IO KC Masinter is to review
STREAMS KC Masinter is to review
FILE KC Masinter is to review
CONTROL KC Masinter is to review
PROGRAM KC Masinter is to review
MISC KC Masinter is to review
ERRORS KC Moon is to review
MACROS KC Done
PACKAGES KC Moon is to review
CHARACTERS KC Moon is to review
EVALUATOR KC Moon is to review
∂30-May-89 0823 Quinquevirate-mailer question @ COPY-SEQ
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 May 89 08:23:38 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA27745; Tue, 30 May 89 08:25:05 PDT
Message-Id: <8905301525.AA27745@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA27745; Tue, 30 May 89 08:25:05 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 30 May 89 10:52
To: quinquevirate@sail.stanford.edu
Subject: question @ COPY-SEQ
Does anyone have a problem if I change the predicate in the description
from EQUALP to EQL?
kathy
∂30-May-89 0938 Quinquevirate-mailer question @ COPY-SEQ
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 30 May 89 09:38:10 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 602735; 30 May 89 12:39:20 EDT
Date: Tue, 30 May 89 12:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: question @ COPY-SEQ
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8905301525.AA27745@decwrl.dec.com>
Message-ID: <19890530164328.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: 30 May 89 10:52
From: chapman%aitg.DEC@decwrl.dec.com
Does anyone have a problem if I change the predicate in the description
from EQUALP to EQL?
Yes, that would be completely wrong! What CLtL says is correct.
It's true that one could invent a stronger predicate than EQUALP
which COPY-SEQ would be an identity under, in particular, one that
was case-sensitive for character and string comparison. However,
among the existing Common Lisp predicates, EQUALP is the only one
under which COPY-SEQ is an identity function.
∂30-May-89 1153 Quinquevirate-mailer copy-seq
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 30 May 89 11:52:57 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Tue, 30 May 89 14:52:12 EDT
Date: Tue, 30 May 89 14:51 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: copy-seq
To: chapman%aitg.DEC@decwrl.dec.com, quinquevirate@sail.stanford.edu
In-Reply-To: <8905301723.AA07295@decwrl.dec.com>
Message-Id: <19890530185146.7.BARMAR@OCCAM.THINK.COM>
Date: 30 May 89 13:18
From: chapman%aitg.DEC@decwrl.dec.com
Here's your original comment.
> >P. 3-217, COPY-SEQ: In the description, remove the clause "that is
> >EQUALP to sequence", and add the sentence "The elements of the result
> >are EQL to the corresponding elements of sequence." The fact that the
> >result is EQUALP is not part of the definition of COPY-SEQ, it's merely
> >a consequence of the definition of EQUALP. If you want to mention
> >EQUALP, you can add this to the Notes: "(EQUALP X (COPY-SEQ X)) ->
> >true". But since it's already in the Examples, it's not really
> >necessary.
> I understand what you're saying, but on page 248 of CLtL, the predicate
> used is EQUALP, so I'll leave it that way.
>
>This has to do with the difference between a language SPECIFICATION and
>an informal language DESCRIPTION. CLtL is a description; we are
>supposed to be writing a precise specification. Simply stating that the
>result is EQUALP to the original is not precise enough; there are many
>ways to copy a sequence that result in an EQUALP-but-not-EQL copy. If
>you think I should write a cleanup proposal for this, I will; however, I
>think it is so obviously what was intended that it isn't necessary.
I'll send a note to the drafting committee so we won't have yet another
issue at the June meeting. ok?
Here's moon's response to your suggestion.
>From: DECWRL::"Moon@STONY-BROOK.SCRC.Symbolics.COM" "David A. Moon 30-May-89 1243 EDT" 30-MAY-1989 12:39:48.36
>To: aitg::chapman
>CC:
>Subj: question @ COPY-SEQ
>
>Cc: quinquevirate@sail.stanford.edu
>
> Date: 30 May 89 10:52
> From: chapman%aitg.DEC@decwrl.dec.com
>
> Does anyone have a problem if I change the predicate in the description
> from EQUALP to EQL?
>
>Yes, that would be completely wrong! What CLtL says is correct.
>It's true that one could invent a stronger predicate than EQUALP
>which COPY-SEQ would be an identity under, in particular, one that
>was case-sensitive for character and string comparison. However,
>among the existing Common Lisp predicates, EQUALP is the only one
>under which COPY-SEQ is an identity function.
Barmar, if you continue this debate, please copy me on it.
kc
Kathy is twisting my words; I DIDN'T say to change EQUALP to EQL! I
said that "COPY-SEQ creates a copy of sequence that is EQUALP to
sequence." is not a good definition (COPY-TREE fits that description,
but we wouldn't want COPY-SEQ to do a COPY-TREE), and should be replaced
with "COPY-SEQ creates a copy of sequence. The elements of the result
are EQL to the corresponding elements of sequence." The Notes section
could then mention that the result is EQUALP to the argument.
CLtL isn't very specific about what goes on when things are copied in
many cases. COPY-SEQ is described in terms of SUBSEQ, but neither of
them explicitly prohibits the implementation from copying other than
just the backbone of the sequence. However, I definitely think this
restriction was intended, and I doubt any implementation is violating
it. Now that I've discovered this ambiguity, I think the ANS should fix
it.
Part of the reason for these types of ambiguities is that the author
assumes that the reader understands the relationships between Lisp
objects. When speaking of "the sequence", "the array", "the list", Lisp
wizards understand that this only refers to the backbone structure, and
doesn't include the elements contained by the object. But less wizardly
implementors might not have our background, and we owe it to them to be
explicit. Otherwise, Murphy's law implies that someone is going to do
(defun copy-seq (seq)
(typecase seq
(list (copy-tree seq))
...))
I haven't even mentioned the fact that the COPY-SEQ description in the
dANS doesn't say that it always returns a newly-allocated sequence (CLtL
says this indirectly, because COPY-SEQ is defined in terms of SUBSEQ,
which says it explicitly, but the dANS only mentions SUBSEQ in the
Notes, which don't count). Therefore, according to the dANS, it's
possible for
(eql (copy-seq foo) (copy-seq foo))
to be true.
∂30-May-89 1305 Quinquevirate-mailer copy-seq
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 30 May 89 13:05:18 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 602956; 30 May 89 16:06:29 EDT
Date: Tue, 30 May 89 16:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: copy-seq
To: chapman%aitg.DEC@decwrl.dec.com, Barry Margolin <barmar@Think.COM>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <19890530185146.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890530201024.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Tue, 30 May 89 14:51 EDT
From: Barry Margolin <barmar@Think.COM>
"COPY-SEQ creates a copy of sequence. The elements of the result
are EQL to the corresponding elements of sequence." The Notes section
could then mention that the result is EQUALP to the argument.
That is a good rewording. I would not bother with the suggested note,
the cross-reference to EQUALP can just be dropped.
In CLtL, COPY-SEQ doesn't say what the type of its result is, except
that presumably it inherits the remark under SUBSEQ "The result
subsequence is always of the same type as the argument -sequence-."
This latter remark is manifestly false, as it would require
(typep (subseq (list 1 2) 1 1) 'cons) to be true, which is impossible.
Furthermore, it conflicts with the remark on the previous page "Whenever
a sequence function must construct and return a new vector, it always
returns a -simple- vector. Similarly, any strings constructed will be
simple strings." Also the concept "of type" is too ill-defined in
Common Lisp to be appropriate to use in this way (cf. TYPE-OF). Under
REVERSE, REMOVE, and DELETE, CLtL uses the word "kind" which may or may
not mean the same thing as "type".
I would guess that the intention is as follows:
If the first argument to SUBSEQ, COPY-SEQ, or REVERSE is a vector, the
result is a freshly-allocated simple-array of rank 1 that has the same
array-element-type as the argument. If the first argument to SUBSEQ,
COPY-SEQ, or REVERSE is a list, the result is a freshly-allocated list.
If the sequence argument to NREVERSE, REMOVE, REMOVE-IF, REMOVE-IF-NOT,
DELETE, DELETE-IF, DELETE-IF-NOT, REMOVE-DUPLICATES, DELETE-DUPLICATES,
SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE,
NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT, SORT, or STABLE-SORT is a vector,
the result is a vector that has the same array-element-type as the
argument. The result may or may not be simple and may or may not be EQ
to the argument. If the sequence argument to NREVERSE, REMOVE,
REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF, DELETE-IF-NOT,
REMOVE-DUPLICATES, DELETE-DUPLICATES, SUBSTITUTE, SUBSTITUTE-IF,
SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT,
SORT, or STABLE-SORT is a list, the result is a list.
Alternatively, the intention may have been that the fourth sentence
above:
The result may or may not be
simple and may or may not be EQ to the argument.
should be:
The result may or may not be EQ to the argument. If the result is
a vector that is not EQ to the argument, the result is a
freshly allocated simple-array of rank 1.
Do we need to run a cleanup issue for this? I think it can just be
handled editorially if all the members of the drafting committee agree.
CLtL isn't very specific about what goes on when things are copied in
many cases. COPY-SEQ is described in terms of SUBSEQ, but neither of
them explicitly prohibits the implementation from copying other than
just the backbone of the sequence. However, I definitely think this
restriction was intended, and I doubt any implementation is violating
it. Now that I've discovered this ambiguity, I think the ANS should fix
it.
Agreed.
I haven't even mentioned the fact that the COPY-SEQ description in the
dANS doesn't say that it always returns a newly-allocated sequence (CLtL
says this indirectly, because COPY-SEQ is defined in terms of SUBSEQ,
which says it explicitly, but the dANS only mentions SUBSEQ in the
Notes, which don't count).
Right, it needs to say this. See above.
∂01-Jun-89 0745 Quinquevirate-mailer Re: 4.2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Jun 89 07:45:49 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA22365; Thu, 1 Jun 89 08:46:04 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA14501; Thu, 1 Jun 89 08:45:56 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906011445.AA14501@defun.utah.edu>
Date: Thu, 1 Jun 89 08:45:55 MDT
Subject: Re: 4.2
To: chapman%aitg.DEC@decwrl.dec.com
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com, 30 May 89 17:35
I'm having a hard time identifying exactly what changes you've made to
the language in this section since the draft I sent you earlier (all
of the TeX stuff makes this extremely difficult to read), but here's
an attempt to answer some of the questions I saw. Some of the other
rewordings you did looked a little awkward to me, but I really want to
be able to look at a readable hardcopy of the whole section before
trying to make suggestions about that kind of thing.
> The term source code is used to refer to the {\word objects\/} constructed
> by
> {\function compile-file\/},
> and additional {\word objects\/} constructed by
> macroexpansion during {\function compile-file\/}.
>
> %[rpg: I think the source code is whatever the representation is in
> %whatever a file is. I think this use of READ as a semantic crutch is
> %unnecessary.]
I disagree. "Objects constructed by COMPILE-FILE" is not specific
enough and could be taken to refer to objects that COMPILE-FILE
constructs and uses internally during the process of compilation, such
as intermediate code or register mappings. I think the original
definition makes it clear what objects we're talking about.
Re the requirement that COMPILE-FILE uses READ. This is indeed stated
explicitly in CLtL (on page 69) and also in the
EVAL-WHEN-NON-TOP-LEVEL proposal we voted in at the last meeting.
That inclusion was deliberate -- it's important to state somewhere
along the line that COMPILE-FILE uses the normal reader mechanisms --
and I would object very strongly to removing it. I would object even
more strongly to removing it as an editorial decision without bringing
it up for a vote before X3J13 first. (I don't know exactly what the
charter of the drafting committee is, but I thought the intent was
that you guys are supposed to turn the decisions made by X3J13 into
words in the standard, not ignore those decisions and write the
standard the way you think it should be.)
> %% Moving the following two bullets to 4.1
I don't understand why, since these two items deal with actions that
must be performed at compile-time. Where exactly in section 4.1 are
you planning to move them?
> %[rpg: There is a complicated issue: Can the compiler assume that the
> %resulting code in a compile-file situation will be run in the same
> %Lisp? The same implementation? The same computer? The same type of
> %computer?
We've made a conscious decision in the compiler committee not to
address problems relating to cross-compilation. Kent claims that it's
impossible to do a fully general cross-compiler, and in any case I
thought we'd be unlikely to resolve all the problems within a reasonable
timeframe.
> In the discussion that follows, the
> compiler can assume that when doing {\function compile-file\/},
> the resulting
> code will be loaded into a fresh copy of the same Lisp.
I would rather leave this out and have the standard remain silent on
this question. I don't think it's particularly relevant to what's
being discussed in this section, anyway.
> Also, the compile time
> environment means definitions made in the file being
> compiled or definitions made in the Lisp running the compiler, either
> before calling
> {\function compile-file\/} or inside {\tt (eval-when compile ...)\/}
> in the file.
I don't think we've actually stated anywhere in our proposals that
this must be the case. I don't think we've voted on anything that
would prohbit you from implementing COMPILE-FILE by having it spawn a
fresh process that contains only the standard Lisp environment and
nothing else that happens to be present in the Lisp in which the user
invoked the COMPILE-FILE function. The compiler committee initially
wasted a lot of time discussing this issue and we eventually decided
to punt on the question and move on to more productive things.
Anyway, once again I think it would be better to remain mute on this
question than to put something in the standard that hasn't actually
been approved by X3J13. At least at one time this was a controversial
issue and I don't think it would be right to sneak it in as an
editorial change.
> A reference to the compiler
> means the {\function compile\/} function
> and implicit compilation, for which the compile time environment and the
> run time environment are two different states of the same Lisp at different
> times.
I'm not sure what point this sentence is trying to make. A reference
to the compiler can also mean the function COMPILE-FILE, but the
second part of it is true only of COMPILE and implicit compilation.
I've kind of gotten used to Kent's terminology of using "file
compiler" and "run-time compiler" to distinguish the two different
kinds of compilation in contexts where it makes a difference, and
using "compiler" as a term that includes both kinds of compilation.
Certainly in the discussion in question here, "compiler" includes both
kinds.
> %[rpg: the interpreter can assume the same thing, right? That is, a
> %valid Common Lisp has be one in all code is compile-filed by a
> %separate program and loaded and executed in the apparent Common Lisp
> %image.]
I don't understand this remark. Yes, all of these things also apply
to the evaluator. The difference is that the evaluator is effectively
allowed to do both compilation and execution at the same time, so the
time at which things are allowed to happen is not so important. This
whole section is trying to address the question of what things happen
during compilation and what things happen during execution, when those
two times aren't necessarily the same.
> % The following paragraph from issue COMPILE-ENVIRONMENT-CONSISTENCY
> % seems likely to change:
>
> \itemitem{\bull}
> The compiler can assume that type definitions made with
> {\function deftype\/}
> or
> {\function defstruct\/} in the compile time environment will retain the same
> definition in the run time environment. It can also assume that
> a class defined by
> {\function defclass\/} in the compile time environment will
> be defined in the run time environment in such a way as to have
> the same {\word superclasses\/} and compatible metaclass.
> %[rpg: compatible metaclass?]
I'm confused. Where did this language come from? It's not the
current language in the COMPILE-ENVIRONMENT-CONSISTENCY proposal, and
it's not the language of Gregor's proposed amendment either. Does
this represent the new position of the CLOS people on this issue (that
I haven't been told about)?
-Sandra
-------
∂01-Jun-89 1343 Quinquevirate-mailer Re: 4.2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Jun 89 13:43:19 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA15381g; Thu, 1 Jun 89 13:41:21 PDT
Received: by challenger id AA12155g; Thu, 1 Jun 89 13:40:17 PDT
Date: Thu, 1 Jun 89 13:40:17 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906012040.AA12155@challenger>
To: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
Subject: Re: 4.2
> The term source code is used to refer to the {\word objects\/}
> constructed
> by
> {\function compile-file\/},
> and additional {\word objects\/} constructed by
> macroexpansion during {\function compile-file\/}.
>
> %[rpg: I think the source code is whatever the representation is in
> %whatever a file is. I think this use of READ as a semantic crutch is
> %unnecessary.]
I disagree. "Objects constructed by COMPILE-FILE" is not specific
enough and could be taken to refer to objects that COMPILE-FILE
constructs and uses internally during the process of compilation, such
as intermediate code or register mappings. I think the original
definition makes it clear what objects we're talking about.
I agree that the proposed rewording doesn't capture the right information.
Maybe this:
*************
The term source code is used to refer to two things:
* the {\word objects\/} constructed by {\function compile-file\/}
corresponding to the objects that READ would have produced on the
same input
* additional {\word objects\/} constructed by macroexpansion during
{\function compile-file\/}.
*************
Re the requirement that COMPILE-FILE uses READ. This is indeed stated
explicitly in CLtL (on page 69) and also in the
EVAL-WHEN-NON-TOP-LEVEL proposal we voted in at the last meeting.
On page 69 it states:
``The EVAL-WHEN construct may be more precisely understood in terms of
a model of how the compiler processes forms in a file to be compiled.
Successive forms are read from the file using the function READ.''
I take the term ``model'' seriously, and I agree that the wording
should be `...as if read using READ....'', but I am not happy with
requiring READ to actually be used. It is an open question whether
some particular functions are identified that are actually used during
input.
The reason I object to explicit use of READ is that there are
legitimate Common Lisp environments in which there is no such thing as
character-level source code (printed representation). Such an
environment would use abstract syntax trees to represent source code,
and only during printing would anything like an ascii representation
be available. These syntax trees can be grouped into files, and
COMPILE-FILE makes sense on them, but it is senseless to translate
into ascii so that READ can be used. (Sadly READ is specified to take
printed representation.)
... and also in the EVAL-WHEN-NON-TOP-LEVEL proposal we voted in at the
last meeting.
Sounds like you pulled the wool over our eyes.
> %[rpg: There is a complicated issue: Can the compiler assume that the
> %resulting code in a compile-file situation will be run in the same
> %Lisp? The same implementation? The same computer? The same type of
> %computer?
We've made a conscious decision in the compiler committee not to
address problems relating to cross-compilation. Kent claims that it's
impossible to do a fully general cross-compiler
This has nothing to do with cross-compilation, per se. The issue is
that we need to state something about where the compiler can assume
the compiled code will run. Since we are outlining things the compiler
can assume, this seems like an obvious thing to discuss. The two choices
about what to say are:
1. It is assumed the code will be immediately loaded into the very image
the compiler that was just used is in.
2. A fresh copy of the above image.
That is, we state that the user can invoke COMPILE-FILE, and that some
behavior of that function is specified. But we never say what you can
do with the output. Well, we can LOAD it somewhere and it will run.
Where? I think we have to state something about a place that is
guaranteed to work.
> %[rpg: the interpreter can assume the same thing, right? That is, a
> %valid Common Lisp has be one in all code is compile-filed by a
> %separate program and loaded and executed in the apparent Common Lisp
> %image.]
I don't understand this remark. Yes, all of these things also apply
to the evaluator. The difference is that the evaluator is effectively
allowed to do both compilation and execution at the same time, so the
time at which things are allowed to happen is not so important. This
whole section is trying to address the question of what things happen
during compilation and what things happen during execution, when those
two times aren't necessarily the same.
The point is that if there is a statement in the compiler section
about CL semantics, and the same statement is true of the interpreter,
then the statement is about the language and belongs somewhere besides
the compiler section.
> % The following paragraph from issue COMPILE-ENVIRONMENT-CONSISTENCY
> % seems likely to change:
>
> \itemitem{\bull}
> The compiler can assume that type definitions made with
> {\function deftype\/}
> or
> {\function defstruct\/} in the compile time environment will retain the same
> definition in the run time environment. It can also assume that
> a class defined by
> {\function defclass\/} in the compile time environment will
> be defined in the run time environment in such a way as to have
> the same {\word superclasses\/} and compatible metaclass.
> %[rpg: compatible metaclass?]
I'm confused. Where did this language come from? It's not the
current language in the COMPILE-ENVIRONMENT-CONSISTENCY proposal, and
it's not the language of Gregor's proposed amendment either. Does
this represent the new position of the CLOS people on this issue (that
I haven't been told about)?
Since this is exactly your message of April 25 except for the word
``compatible'', you must be asking about that word. First, note that
my comment says ``compatible metaclass?'' whilst your original said
``same ... metaclass.'' My question is whether we want to restrict the
metaclass to be the same or is it allowed to be some simpler one?
Here is an *analogy*. The type INTEGER is defined in Common Lisp. A
fancy compiler might be able to correctly determine that where
INTEGERs are used only fixnums are needed. Therefore, the compiler can
assume that the metaclass of INTEGER can be specialized to the one for
FIXNUM. Rather than restrict the smarts to subclasses of metaclasses,
I conjectured a useful term might be ``compatible'', which the CLOS
crowd threw around for a while.
[note: the reason subclass of metaclass is not sufficient is that
the object might have fewer operations done on it so that the
metaclass can support fewer operations (such as not supporting
slot-value), and so it's actually something like a superclass of
the metaclass that is simpler and which the compiler can assume.
Hence, the term ``compatible.'']
-rpg-
∂02-Jun-89 0744 Quinquevirate-mailer Re: 4.2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Jun 89 07:44:24 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA08851; Fri, 2 Jun 89 08:44:31 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA15145; Fri, 2 Jun 89 08:44:28 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906021444.AA15145@defun.utah.edu>
Date: Fri, 2 Jun 89 08:44:26 MDT
Subject: Re: 4.2
To: Richard P. Gabriel <rpg@lucid.com>
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Thu, 1 Jun 89 13:40:17 PDT
> The term source code is used to refer to two things:
>
> * the {\word objects\/} constructed by {\function compile-file\/}
> corresponding to the objects that READ would have produced on the
> same input
>
> * additional {\word objects\/} constructed by macroexpansion during
> {\function compile-file\/}.
This is a lot better than what's there now, but I still prefer the
original wording.
> The reason I object to explicit use of READ is that there are
> legitimate Common Lisp environments in which there is no such thing as
> character-level source code (printed representation). Such an
> environment would use abstract syntax trees to represent source code,
> and only during printing would anything like an ascii representation
> be available. These syntax trees can be grouped into files, and
> COMPILE-FILE makes sense on them, but it is senseless to translate
> into ascii so that READ can be used. (Sadly READ is specified to take
> printed representation.)
I don't think this is a problem. Every conforming implementation must
have a notion of files which contain characters and be able to READ
from those files. I don't think that requiring COMPILE-FILE to be
able to READ these files is a great hardship on implementations that
also happen to support files containing source code in some other
structured representation. Of course, these implementations would
probably also want to extend COMPILE-FILE to also accept the
structured input files.
> This has nothing to do with cross-compilation, per se. The issue is
> that we need to state something about where the compiler can assume
> the compiled code will run. Since we are outlining things the compiler
> can assume, this seems like an obvious thing to discuss. The two choices
> about what to say are:
>
> 1. It is assumed the code will be immediately loaded into the very image
> the compiler that was just used is in.
>
> 2. A fresh copy of the above image.
There is a third choice which I think is probably more correct: the
code can be loaded into either of the above.
I think the use of the word "fresh" in choice number 2 might have the
wrong connotations here. To me it implies a completely clean
environment containing nothing but the symbols and definitions that
are initially provided by the implementation. I think that what you
really want to say is that the copy *might* be a fresh copy, but leave
open the possibility that it could contain other user-supplied
definitions as well (for example, as a result of previously loading
some other files). Likewise, I would strike the word "immediately"
from choice number 1.
> The point is that if there is a statement in the compiler section
> about CL semantics, and the same statement is true of the interpreter,
> then the statement is about the language and belongs somewhere besides
> the compiler section.
You're probably right -- chapter 4 could be reorganized to present the
evaluation model in terms of two distinct phases (syntactic analysis
and execution) and this entire discussion about implicit compilation
and which phase various things happen in moved there, and what is now
section 4.2 should probably concentrate only on aspects of compilation
that are peculiar to COMPILE-FILE. I don't think I've got authority
to do that on my own (it's certainly beyond the scope of what Kathy
originally asked me to do), but I guess that's the kind of decision
you guys on the drafting committee are supposed to be making.
> Since this is exactly your message of April 25 except for the word
> ``compatible'', you must be asking about that word. First, note that
> my comment says ``compatible metaclass?'' whilst your original said
> ``same ... metaclass.'' My question is whether we want to restrict the
> metaclass to be the same or is it allowed to be some simpler one?
I understand what you meant by using "compatible" here. My question
is, is this new wording you suggest something that you would prefer to
the amendment that was offered at the last meeting (which said
something quite different), and is that your own personal opinion or
are you speaking for the CLOS cabal? To tell the truth, I think that
amendment is going to open up a can of worms and I'd really like to
find some other compromise position.
-Sandra
-------
∂02-Jun-89 0915 Quinquevirate-mailer 4.2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Jun 89 09:15:48 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA03684g; Fri, 2 Jun 89 09:14:35 PDT
Received: by challenger id AA00397g; Fri, 2 Jun 89 09:13:50 PDT
Date: Fri, 2 Jun 89 09:13:50 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906021613.AA00397@challenger>
To: sandra%defun@cs.utah.edu
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 2 Jun 89 08:44:26 MDT <8906021444.AA15145@defun.utah.edu>
Subject: 4.2
This is a lot better than what's there now, but I still prefer the
original wording.
I wouldn't expect less.
I don't think this is a problem. Every conforming implementation must
have a notion of files which contain characters and be able to READ
from those files.
Oh? This is an logically valid implication from CLtL, where it implies
use of READ during LOAD and suggests a model for COMPILE-FILE that
uses READ. READ is the only place (I think) where the use of a printed
representation is required. I think we should abandon this requirement.
I don't think that requiring COMPILE-FILE to be
able to READ these files is a great hardship on implementations that
also happen to support files containing source code in some other
structured representation. Of course, these implementations would
probably also want to extend COMPILE-FILE to also accept the
structured input files.
Using your requirement of using READ, any use of COMPILE-FILE would
need to operate on a printed representation. The reason to not use
printed representation is to avoid the cost of parsing tokens which in
most compilers and such tools is the highest single performance
problem. So you're suggesting as the no-problem solution the very thing
these implementations went to the trouble to avoid. Cruel.
Of course, these implementations would probably also want to extend
COMPILE-FILE to also accept the structured input files.
Not if COMPILE-FILE uses READ. Are we still talking about the same thing?
I think the use of the word "fresh" in choice number 2 might have the
wrong connotations here. To me it implies a completely clean
environment containing nothing but the symbols and definitions that
are initially provided by the implementation. I think that what you
really want to say is that the copy *might* be a fresh copy, but leave
open the possibility that it could contain other user-supplied
definitions as well (for example, as a result of previously loading
some other files). Likewise, I would strike the word "immediately"
from choice number 1.
If we say the copy *might* be a fresh copy, we should also say that
the compiled code *might* work. What I want to see clearly explained
is a prescription of the structure of a compilation unit, a
compilation scenario, and a load scenario that is guaranteed to work
in every conforming Common Lisp. Maybe some others will work, and we
can state some general directions for extension that should work. But
we absolutely must specify the safe scenario.
I understand what you meant by using "compatible" here. My question
is, is this new wording you suggest something that you would prefer to
the amendment that was offered at the last meeting (which said
something quite different), and is that your own personal opinion or
are you speaking for the CLOS cabal? To tell the truth, I think that
amendment is going to open up a can of worms and I'd really like to
find some other compromise position.
I was simply mentioning another possibility. The same metaclass
proposal is certainly safe, but maybe overly so. My comment on your
draft, which I phrased as a question, was not meant to trigger any
particular action. Maybe Moon has an opinion?
-rpg-
∂02-Jun-89 1100 Quinquevirate-mailer Re: 4.2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Jun 89 10:59:32 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA14842; Fri, 2 Jun 89 11:59:43 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA15296; Fri, 2 Jun 89 11:59:41 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906021759.AA15296@defun.utah.edu>
Date: Fri, 2 Jun 89 11:59:38 MDT
Subject: Re: 4.2
To: Richard P. Gabriel <rpg@lucid.com>
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Fri, 2 Jun 89 09:13:50 PDT
> READ is the only place (I think) where the use of a printed
> representation is required. I think we should abandon this requirement.
Then your complaint doesn't really have anything to do with
COMPILE-FILE per se -- if COMPILE-FILE uses READ, and READ is extended
to read structured files, then COMPILE-FILE will do exactly what you
want, and there's no reason to make any chantes to its specification.
(Again, I think it would be legitimate for an implementation to extend
READ in this manner even if the standard only defines its behavior on
character streams.)
> If we say the copy *might* be a fresh copy, we should also say that
> the compiled code *might* work. What I want to see clearly explained
> is a prescription of the structure of a compilation unit, a
> compilation scenario, and a load scenario that is guaranteed to work
> in every conforming Common Lisp. Maybe some others will work, and we
> can state some general directions for extension that should work. But
> we absolutely must specify the safe scenario.
I've been taking a rather different approach to this -- instead of
trying to specify in what circumstances that loading a compiled file
will "work", I've been thinking more in terms of specifying in what
circumstances a file can be compiled so that it will *always* load
correctly when compiled. (Of course, a program might not work for
reasons that have nothing to do with compilation, so effectively we're
trying to get loading the compiled version to exhibit the same
behavior as loading the interpreted version.)
Since compilation involves making some decisions about the program
(what forms are macro calls, possibly making inferences about the
types of objects manipulated by the program, etc.) at compile time,
the equivalence of source and compiled code may not hold if the
information the compiler used to make these decisions has changed when
the file is loaded. So the section we're talking about here is trying
to say what kinds of information the compiler might incorporate into
the code and what happens (whether the consequences are undefined or
unspecified) if the information that was visible at compile time is
not defined consistently with the information that is visible at load
time. I don't think it's necessary to place any additional
constraints on the Lisp image being "fresh", or the compiled file
being loaded "immediately". What's more, I don't think there's any
*reason* for adding such an arbitrary constraint. We might just as
well say that it's only valid to load the compiled code on the night
of a full moon.
-Sandra
-------
∂02-Jun-89 1747 Quinquevirate-mailer Condition System Rewrite
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Jun 89 17:47:38 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA01715g; Fri, 2 Jun 89 17:46:23 PDT
Received: by challenger id AA01171g; Fri, 2 Jun 89 17:45:36 PDT
Date: Fri, 2 Jun 89 17:45:36 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906030045.AA01171@challenger>
To: quinquevirate@sail.stanford.edu
Subject: Condition System Rewrite
I have just completed my first pass rewrite of the condition system
chapter. While doing this I noticed some omissions. I wonder whether
we need to go to X3J13 to fix these or whether we can simply add the
right stuff.
First, the precise order of search for handlers is not specified. It
states that a dynamically inner handler-bind, for example, establishes
handlers that are more specific than outer ones, but there is no order
specified within a handler-bind. Because the order matters only when
two handlers apply to the same condition, I suggest the rule be the
same as the class precedence list order. When handlers simply return
values and hence keep invoking the next one, this is simply
call-next-method order. Pitman's code finds the first one that applies
within a cluster according to the order they were pushed onto the
cluster. I think this is wrong. He also punts the cluster if the handler
simply returns and searches the next one. His comment on this line of
code is
(return nil) ;?
I think this is wrong. Lucid continues within the cluster, but in the
same random order as Pitman's code would if the (return nil) were
deleted. Better, but still wrong.
It is not specified what happens if handler-bind supplies two handlers
for the same type. Same for handler-case.
It is also not specified what happens if restart-bind supplies two
restarts with the same name (nil doesn't count). Same for
handler-case.
I suggest ``unspecified'' for what happens in these cases.
Kathy, I need another day or so to proof my draft, then I'll let you
have a gander.
-rpg-
∂02-Jun-89 2243 Quinquevirate-mailer More on Conditions
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Jun 89 22:43:31 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA03021g; Fri, 2 Jun 89 22:42:16 PDT
Received: by challenger id AA01377g; Fri, 2 Jun 89 22:41:29 PDT
Date: Fri, 2 Jun 89 22:41:29 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906030541.AA01377@challenger>
To: quinquevirate@sail.stanford.edu
Subject: More on Conditions
I forgot to add that I didn't like the name ``cell-error'' for that
type. Recall that the two subtypes are named ``unbound-variable'' and
``undefined-function''. Since these equally apply to lexical variables
and functions, cells have little to do with it.
In Pitman's original text, he says that this type of error occurs when
accesing locations, so I think a better name is ``access-error''.
Opinions?
-rpg-
∂04-Jun-89 1949 Quinquevirate-mailer More on Conditions
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jun 89 19:49:19 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA12029g; Sun, 4 Jun 89 19:47:58 PDT
Received: by challenger id AA02547g; Sun, 4 Jun 89 19:47:08 PDT
Date: Sun, 4 Jun 89 19:47:08 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906050247.AA02547@challenger>
To: quinquevirate@sail.stanford.edu
Subject: More on Conditions
On further reading I see that handler-bind conditions are searched in
left-to-right order, as is handler-case. On further reflection, I
think handler-case should do this, but not handler-bind, especially
when there is the type-hierarchy-imposed order that is more
interesting than left-to-right. handler-BIND isn't especially
reminiscent of <anything>-CASE. Presumably implementations can
CLOSize conditions using multiple inheritance, which makes this
There seems little need for restart-case, if you ask me.
Grumble, this is what you get when you assume X3J13 is reading these
proposals carefully for consideration. The original writeup is so
goofy, no one can understand it.
Opinions? If there is no comment, I'll submit my rewritten draft
which defines the behavior of handler-bind and handler-case as
proposed, but leaves restart-bind and restart-case as is.
-rpg-
Kathy: As soon as I can get to terminal on which I can observe TEX
output so I can change the sizes of some rules, I'll netmail the
chapter to you. The new version is about 3100 words while the original
is about 6500.
∂05-Jun-89 0918 Quinquevirate-mailer 4.2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Jun 89 09:18:01 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA15144g; Mon, 5 Jun 89 09:16:37 PDT
Received: by challenger id AA03765g; Mon, 5 Jun 89 09:15:22 PDT
Date: Mon, 5 Jun 89 09:15:22 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906051615.AA03765@challenger>
To: sandra%defun@cs.utah.edu
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 2 Jun 89 11:59:38 MDT <8906021759.AA15296@defun.utah.edu>
Subject: 4.2
if COMPILE-FILE uses READ, and READ is extended
to read structured files, then COMPILE-FILE will do exactly what you
want, and there's no reason to make any chantes to its specification.
Yes, however, I believe the antecedent is false, hence I push on
COMPILE-FILE, which doesn't currently require READ. READ discusses
printed representation explicitly, so changing it is hard.
I've been taking a rather different approach to this -- instead of
trying to specify in what circumstances that loading a compiled file
will "work", I've been thinking more in terms of specifying in what
circumstances a file can be compiled so that it will *always* load
correctly when compiled.
Well, you must be a lot smarter than I am, because I cannot see how
you can specify that the compilation and loading processes will always
work without some constraints on both the compiler process and loader
process.
(Of course, a program might not work for reasons that have nothing to
do with compilation, so effectively we're trying to get loading the
compiled version to exhibit the same behavior as loading the
interpreted version.)
By the way, conforming source code is supposed to work in any
conforming Common Lisp, but that same code compiled probably does not.
So I guess we cannot achieve your ideal.
If I were a total novice in Common Lisp, I'd rather know how to make a
program I wrote display the semantics I think it should have rather
than know that interpreted and compiled code behaved the same (but not
how I intended it).
Since we're trying specify Common Lisp, it seems we should trying to
specify how a correct program can be correctly run. I think other
languages care about this.
I don't think it's necessary to place any additional constraints on
the Lisp image being "fresh", or the compiled file being loaded
"immediately". What's more, I don't think there's any *reason* for
adding such an arbitrary constraint.
I guess your own parenthetical remark doesn't hold water with you.
-rpg-
∂05-Jun-89 0954 Quinquevirate-mailer Re: 4.2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Jun 89 09:53:55 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA19520; Mon, 5 Jun 89 10:54:12 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA16940; Mon, 5 Jun 89 10:54:07 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906051654.AA16940@defun.utah.edu>
Date: Mon, 5 Jun 89 10:54:06 MDT
Subject: Re: 4.2
To: Richard P. Gabriel <rpg@lucid.com>
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Mon, 5 Jun 89 09:15:22 PDT
I'm getting confused about exactly what you're after here. If you
want to say that a compiled file is guaranteed to load correctly only
in the implementation it was originally compiled in, that's OK with me
(although I think it goes without saying since the standard leaves the
format of such files unspecified). But I still don't understand why
you think it's necessary to require things like the compiled file
aving to be loaded into a "fresh" copy of the Lisp image. Can you be
more specific about the rationale for doing this? What particular
advantage does it buy implementors that would justify putting such a
restriction on users? What kinds of things would the compiler be
assuming about the code that would be invalidated if it were not
loaded into a "fresh" image? Among other things, this restriction
implies that you can't load more than one compiled file, since the
image would no longer be "fresh" after loading the first one. I don't
think any existing implementation is currently this restrictive, and I
imagine that any implementation that did place such restrictions would
be dismissed as a toy.
Like I said before, I feel very uncomfortable with the idea of changes
in content like this being stuck into the standard at the last minute
using only the editorial process, without first having some discussion
and a vote of X3J13 as a whole. If you want to write up a specific
proposal on this, though, I'm willing to bring it up for consideration
at the meeting later this month, along with the rest of the unresolved
cl-compiler issues.
-Sandra
-------
∂05-Jun-89 1002 Quinquevirate-mailer 4.2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Jun 89 10:02:20 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA15357g; Mon, 5 Jun 89 10:00:57 PDT
Received: by challenger id AA04095g; Mon, 5 Jun 89 10:00:05 PDT
Date: Mon, 5 Jun 89 10:00:05 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906051700.AA04095@challenger>
To: sandra%defun@cs.utah.edu
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 5 Jun 89 10:54:06 MDT <8906051654.AA16940@defun.utah.edu>
Subject: 4.2
(although I think it goes without saying since the standard leaves the
format of such files unspecified)
The first thing to realize is that nothing goes without saying. We
cannot begin to imagine the sort of backgrounds people will have when
they read this.
What I'm saying in general is simple. I want to specify that if a user
does X, his code is guaranteed to to work according to Common Lisp
semantics. If the user does something besides X, it still might work.
I don't want a reader of the spec to wonder how to get a simple
program to work. Nothing I'm suggesting is a restriction on what the
user can do. The issue that passed and that disallowed changes to the
LISP package symbols makes specification of X easier.
-rpg-
∂05-Jun-89 1043 Quinquevirate-mailer Re: 4.2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Jun 89 10:43:08 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21302; Mon, 5 Jun 89 11:43:25 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA16972; Mon, 5 Jun 89 11:43:21 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906051743.AA16972@defun.utah.edu>
Date: Mon, 5 Jun 89 11:43:20 MDT
Subject: Re: 4.2
To: Richard P. Gabriel <rpg@lucid.com>
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Mon, 5 Jun 89 10:00:05 PDT
I'm sorry, but the language that's now in the draft Kathy sent me does
indeed look like it places restrictions on what users can do. To me
it carries a strong implication that the only portable usage of
COMPILE-FILE and LOAD is when the compiled file is loaded into a
"fresh" Lisp image.
If your goal is really to give users a hint about how to structure
their programs so that they'll be guaranteed to work in all
implementations, saying that the compiler can assume that the code
will be loaded into a "fresh" Lisp image does not really help in that
direction at all. Maybe what you really want to do is to put some
additional restrictions on the structure of conforming programs?
Since the conformance-position proposal has not yet been sorted out,
one thing I've been assuming is that not all programs will load
correctly in all circumstances, but still be a conforming program.
For example, a file might have a call to a function appearing as a
top-level form, and that function would have to be defined before the
file can be loaded. That would be the case regardless of whether or
not the file being loaded is a source file or a compiled file. If you
want to say that such programs are not conforming, that's OK, but I
think the statement belongs in the discussion of conformance, not the
discussion of compilation semantics, since the question of whether or
not the file is guaranteed to load correctly has nothing to do with
whether the file is in source or compiled form. This is what I was
talking about before when I said that a file might not load correctly
for reasons that have nothing to do with compilation.
Anyway, given some circumstances in which the source program will load
correctly, we can guarantee that the compiled program will also load
correctly in those same circumstances provided that certain conditions
also held when the program was compiled. The purpose of this section
is to describe what those conditions are.
-Sandra
-------
∂05-Jun-89 1050 Quinquevirate-mailer 4.2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Jun 89 10:50:50 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA15590g; Mon, 5 Jun 89 10:49:30 PDT
Received: by challenger id AA04366g; Mon, 5 Jun 89 10:48:41 PDT
Date: Mon, 5 Jun 89 10:48:41 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906051748.AA04366@challenger>
To: sandra%defun@cs.utah.edu
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 5 Jun 89 11:43:20 MDT <8906051743.AA16972@defun.utah.edu>
Subject: 4.2
If your goal is really to give users a hint about how to structure
their programs so that they'll be guaranteed to work in all
implementations, saying that the compiler can assume that the code
will be loaded into a "fresh" Lisp image does not really help in that
direction at all. Maybe what you really want to do is to put some
additional restrictions on the structure of conforming programs?
Now we've worked ourselves back to my original proposal. That is, we
specify well-formed programs, and state that a well-formed program
compiled in a fresh lisp and loaded into a fresh lisp or a well-formed
program loading into a fresh lisp works according to CL semantics.
And maybe it works in a variety of dirty lisps, but we dont's have the
page real estate to talk about all the dirty things you can do to
a Lisp and still have something work.
-rpg-
∂05-Jun-89 1108 Quinquevirate-mailer Re: 4.2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Jun 89 11:08:40 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA22431; Mon, 5 Jun 89 12:08:57 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA17001; Mon, 5 Jun 89 12:08:54 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906051808.AA17001@defun.utah.edu>
Date: Mon, 5 Jun 89 12:08:52 MDT
Subject: Re: 4.2
To: Richard P. Gabriel <rpg@lucid.com>
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Mon, 5 Jun 89 10:48:41 PDT
> Now we've worked ourselves back to my original proposal. That is, we
> specify well-formed programs, and state that a well-formed program
> compiled in a fresh lisp and loaded into a fresh lisp or a well-formed
> program loading into a fresh lisp works according to CL semantics.
This idea is fine with me. The only things I object to are trying to
put this into the middle of a discussion on compilation when it is
really a conformance requirement that applies equally to both
interpreted and compiled programs, and trying to add it into the
standard without first giving the question adequate consideration by
X3J13 as a whole.
-Sandra
-------
∂05-Jun-89 1145 Quinquevirate-mailer 4.2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Jun 89 11:42:40 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA15822g; Mon, 5 Jun 89 11:40:29 PDT
Received: by challenger id AA04550g; Mon, 5 Jun 89 11:39:18 PDT
Date: Mon, 5 Jun 89 11:39:18 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906051839.AA04550@challenger>
To: sandra%defun@cs.utah.edu
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 5 Jun 89 12:08:52 MDT <8906051808.AA17001@defun.utah.edu>
Subject: 4.2
This idea is fine with me. The only things I object to are trying to
put this into the middle of a discussion on compilation when it is
really a conformance requirement that applies equally to both
interpreted and compiled programs....
Cough, cough, you'll recall that my minor remarks on the compilation
chapter asked the question how much of this should apply to both the
compiler and interpreter, and ....
All I'm trying to do is see whether there is some concensus among this
smaller group before doing anything about it in the larger group.
-rpg-
∂05-Jun-89 1228 Quinquevirate-mailer More on Conditions
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 5 Jun 89 12:27:57 PDT
Received: from fafnir.think.com by Think.COM; Mon, 5 Jun 89 15:27:59 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 5 Jun 89 15:26:59 EDT
Received: from joplin.think.com by verdi.think.com; Mon, 5 Jun 89 15:26:57 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Mon, 5 Jun 89 15:26:54 EDT
Date: Mon, 5 Jun 89 15:26:54 EDT
Message-Id: <8906051926.AA04568@joplin.think.com>
To: rpg@lucid.com
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Fri, 2 Jun 89 22:41:29 PDT <8906030541.AA01377@challenger>
Subject: More on Conditions
I agree that "access-error" is a better name.
∂05-Jun-89 1244 Quinquevirate-mailer Re: 4.2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Jun 89 12:44:27 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA26056; Mon, 5 Jun 89 13:44:43 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA17061; Mon, 5 Jun 89 13:44:40 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906051944.AA17061@defun.utah.edu>
Date: Mon, 5 Jun 89 13:44:38 MDT
Subject: Re: 4.2
To: Richard P. Gabriel <rpg@lucid.com>
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Mon, 5 Jun 89 11:39:18 PDT
> Cough, cough, you'll recall that my minor remarks on the compilation
> chapter asked the question how much of this should apply to both the
> compiler and interpreter, and ....
>
> All I'm trying to do is see whether there is some concensus among this
> smaller group before doing anything about it in the larger group.
As I said before, I have no objection to the idea of reorganizing all
of chapter 4 to integrate the discussion of compilation into the
presentation of the evaluation model. I also agree it would probably
be helpful to have the standard specify what a well-formed program is
and that having such a thing might make it possible to simplify parts
of the compiler discussion, but I'd have to see a more detailed
proposal before I could give an opinion on whether the specification
you have in mind is reasonable, or how it should affect the
presentation of the material on compilation.
I do think, though, that just gluing material on constraints on
conforming programs that don't have much to do with the process of
compilation into this section as it stands now confuses (rather than
clarifies) the presentation. And that's what's happened in the draft
Kathy sent me to review.
-Sandra
-------
∂07-Jun-89 1007 Quinquevirate-mailer Condition System Rewrite
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Jun 89 10:07:19 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 607257; 7 Jun 89 13:08:32 EDT
Date: Wed, 7 Jun 89 13:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Condition System Rewrite
To: Richard P. Gabriel <rpg@lucid.com>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8906030045.AA01171@challenger>,
<8906050247.AA02547@challenger>
Message-ID: <19890607171336.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This message is just about the issues of the order of searching handlers
and restarts. I'll reply to the rest separately.
Date: Fri, 2 Jun 89 17:45:36 PDT
From: Richard P. Gabriel <rpg@lucid.com>
While doing this I noticed some omissions. I wonder whether
we need to go to X3J13 to fix these or whether we can simply add the
right stuff.
I'm glad you're checking this for omissions. I think Kent's document
is much more appropriate as a tutorial introduction to the ideas than
as a language standard. As with the rest of Common Lisp, we must be
very careful that no unintended changes to the language definition
are introduced while improving the way that that definition is described,
but at the same time we need a much less ambiguous definition now that
we are exposing the langauge to a wider audience.
As for the process, I think anything that might conflict with current
practice should go through X3J13, since a lot of implementations have
already jumped the gun and implemented some version of the ANSI CL
condition system. Where it's only a clarification of something, and
either all known current practice agrees with what you wrote, or we're
confident no user programs care, I think we might be justified in
bypassing the process in the interests of time.
First, the precise order of search for handlers is not specified. It
states that a dynamically inner handler-bind, for example, establishes
handlers that are more specific than outer ones, but there is no order
specified within a handler-bind. Because the order matters only when
two handlers apply to the same condition, I suggest the rule be the
same as the class precedence list order.
I'm convinced this is wrong. The order of searching handlers should be
the order that they are written, not a more "intelligent" order that
might or might not be what the programmer intended. I don't buy the
analogy to methods here: To me, the type-specifier in front of a
handler in handler-bind is just a convenient abbreviation for a typep
test in the body of the handler, and should be semantically equivalent.
The fact that nested handler-binds are searched in the order of nesting,
not in an order based on type hierarchy, indicates that there is no
strong analogy to methods.
...He also punts the cluster if the handler
simply returns and searches the next one. His comment on this line of
code is
(return nil) ;?
I think this is wrong.
I agree. Every applicable handler should get a chance to handle the
condition. That's how the Symbolics condition system, which this proposal
is supposedly based on, does it, and no one has claimed that that is wrong.
I think that (return nil) is just a bug in Kent's model implementation.
Lucid continues within the cluster, but in the
same random order as Pitman's code would if the (return nil) were
deleted.
I agree that Lucid's implementation is doing the right thing, and I
disagree with the judgement that the order is random.
It is not specified what happens if handler-bind supplies two handlers
for the same type.
They should both run. The effect should be the same as if there was one
handler with both bodies in it, connected with PROGN in the order written.
In my view
(handler-bind ((cond-1 #'(lambda (x) body-1...))
(cond-2 #'(lambda (x) body-2...))
(cond-3 #'(lambda (x) body-3...)))
...)
is syntactic sugar for the semantically equivalent
(handler-bind ((t #'(lambda (x)
(progn
(when (typep x 'cond-1)
body-1...)
(when (typep x 'cond-2)
body-2...)
(when (typep x 'cond-3)
body-3...)))))
...)
Same for handler-case.
This should be the same as a TYPECASE with duplicated clause keys.
The first of the two duplicates is reached, the second is unreachable,
and the compiler is justified in issuing a style warning.
In fact the semantics of duplicates are fully specified for handler-case:
The cases are searched sequentially from top to bottom. If there is type
overlap between the cases, the earlier of the two cases will be selected.
It is also not specified what happens if restart-bind supplies two
restarts with the same name (nil doesn't count). Same for
handler-case. [I assume you mean restart-case]
Since restarts are objects and the name is just incidental, there is nothing
wrong or special about name duplications for restarts. All the restarts
are established. The order in which they appear in the result of
compute-restarts needs to be specified. The only stuff I could find
relevant to this is:
It is possible to have more than one clause use the same CASE-NAME.
In this case, the first clause with that name will be found by
FIND-RESTART. The other clauses are accessible using COMPUTE-RESTARTS.
The specification consistent with this is that compute-restarts lists
restarts in left to right order within a cluster and in inner to outer
order among clusters. That's consistent with handler-bind's order too.
I suggest ``unspecified'' for what happens in these cases.
None of these should be unspecified in my opinion.
Date: Sun, 4 Jun 89 19:47:08 PDT
From: Richard P. Gabriel <rpg@lucid.com>
On further reading I see that handler-bind conditions are searched in
left-to-right order, as is handler-case. On further reflection, I
think handler-case should do this, but not handler-bind, especially
when there is the type-hierarchy-imposed order that is more
interesting than left-to-right. handler-BIND isn't especially
reminiscent of <anything>-CASE. Presumably implementations can
CLOSize conditions using multiple inheritance, which makes this
There seems to be a line missing here. I still maintain that the order
for handler bind should be the order that the programmer wrote, and not
anything derived from type hierarchy. Do you agree or disagree?
∂07-Jun-89 1015 Quinquevirate-mailer Condition System Rewrite: restarts
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Jun 89 10:14:30 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 607262; 7 Jun 89 13:15:49 EDT
Date: Wed, 7 Jun 89 13:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Condition System Rewrite: restarts
To: Richard P. Gabriel <rpg@lucid.com>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8906050247.AA02547@challenger>
Message-ID: <19890607172107.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Sun, 4 Jun 89 19:47:08 PDT
From: Richard P. Gabriel <rpg@lucid.com>
There seems little need for restart-case, if you ask me.
Restarts are certainly a weak point of this proposal. However,
something like restarts is definitely required. Current practice shows
that this is one of the most important parts of the condition system.
Also restart-case is definitely used in preference to restart-bind. Of
course restart-case could have been defined by a user as a macro that
expands into restart-bind, just as handler-case could have been defined
by a user as a macro that expands into handler-bind.
MLY had an interesting proposal to integrate restarts and handlers,
however he pre-assumed that no one would listen to him and never
developed the proposal far enough for it to be considered as an
alternative to Kent's proposal. Too bad, if you ask me. I would have
liked to see restarts done differently, and would like to see something
done with the cleanup issue CONDITION-RESTARTS (although version 1
contains some things that are unacceptable). However, in my judgement
even what is currently in the ANSI CL language is better than no
restarts. It was some weak points, especially in the convenience
features, but it is not bankrupt.
∂07-Jun-89 1025 Quinquevirate-mailer re: Condition System Rewrite
To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, rpg@LUCID.COM
CC: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Wed, 7 Jun 89 13:13 EDT.]
Moon wrote:
I still maintain that the order for handler bind should be the order that
the programmer wrote, and not anything derived from type hierarchy. Do
you agree or disagree?
Over the weekend I ended up agreeing, and the draft I sent Kathy specifies
the left-to-right order for all searches. It actually looks better
described that way than I thought. You can get the ``smart'' behavior with
a general trampoline to a generic function:
(handler-bind
((condition #'(lambda (cond) (really-handle cond))))
(lose-in-a-hurry))
(defmethod really-handle ((c division-by-zero))...) ...
-rpg-
∂07-Jun-89 1037 Quinquevirate-mailer Condition System Rewrite: cell-error
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Jun 89 10:37:16 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 607281; 7 Jun 89 13:38:27 EDT
Date: Wed, 7 Jun 89 13:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Condition System Rewrite: cell-error
To: Richard P. Gabriel <rpg@lucid.com>, Guy Steele <gls@Think.COM>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8906030541.AA01377@challenger>,
<8906051926.AA04568@joplin.think.com>
Message-ID: <19890607174342.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Fri, 2 Jun 89 22:41:29 PDT
From: Richard P. Gabriel <rpg@lucid.com>
I forgot to add that I didn't like the name ``cell-error'' for that
type. Recall that the two subtypes are named ``unbound-variable'' and
``undefined-function''. Since these equally apply to lexical variables
and functions, cells have little to do with it.
I am unaware of any Common Lisp language facilities for creating lexically
local unbound variables and/or undefined functions. However, I agree that
the terminology of "symbol cells" is best abandoned, as it only leads to
confusion between the language and one possible implementation technique.
In Pitman's original text, he says that this type of error occurs when
accesing locations, so I think a better name is ``access-error''.
Date: Mon, 5 Jun 89 15:26:54 EDT
From: Guy Steele <gls@Think.COM>
I agree that "access-error" is a better name.
The name in the Symbolics condition system, for what that's worth,
is SYS:CELL-CONTENTS-ERROR. It has some other subtypes that are
connected with memory access errors (where the problem is with the
contents of the location, not the address of the location). Those
types are not appropriate for the CL language standard, however.
SYS:CELL-CONTENTS-ERROR makes sense as an implementation type but
not as a portable type.
ACCESS-ERROR seems better than CELL-ERROR, but still a bit vague to me.
Are the CLOS condition types SLOT-MISSING and SLOT-UNBOUND subtypes of
ACCESS-ERROR? I think SLOT-UNBOUND should be. I'm unsure about
SLOT-MISSING but I think it should not be, even though from the name
ACCESS-ERROR sounds like it should include it. What about
NO-APPLICABLE-METHOD when the generic function is an accessor? Are
there other errors that might be considered to involve "access"?
What about an array subscript out of bounds, for example?
Aside to Kathy: version 5.14 of section 2.2 is missing the CLOS
condition types.
Aside: I wonder why SLOT-UNBOUND isn't named UNBOUND-SLOT.
Depending on your interpretation of the word "binding", UNBOUND-VARIABLE
and UNDEFINED-FUNCTION might be called BINDING-ERRORs. I like that
better than ACCESS-ERROR, but there is potential for confusion since
Lisp programmers use the word "bind" in so many inconsistent ways.
Unless someone can think of a better name, which is quite possible,
I would prefer to go with BINDING-ERROR.
This rename will definitely have to go through the X3J13 process. I
would not expect much controversy, however.
∂07-Jun-89 1105 Quinquevirate-mailer Condition System Rewrite: cell-error
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jun 89 11:04:52 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA05641g; Wed, 7 Jun 89 11:03:02 PDT
Received: by challenger id AA08181g; Wed, 7 Jun 89 11:02:14 PDT
Date: Wed, 7 Jun 89 11:02:14 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906071802.AA08181@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: gls@Think.COM, quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 7 Jun 89 13:43 EDT <19890607174342.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Subject: Condition System Rewrite: cell-error
If you write
(labels ((qux (x y z) (atanh ...)))
(quux 1 2 3))
It isn't clear to me whether you failed to define the global QUUX or
you failed to define the local QUUX. It is a happenstance that the
``search'' for bindings ends up in the symbol. The name ``cell-error''
implies primacy of symbols. The entire search for a function definition
failed, and the error should not refer to the last part of it.
``I am unaware of any Common Lisp language facilities for creating lexically
local unbound variables and/or undefined functions.''
It is called silence.
I too thought ``binding-error'' was a better name, but I've noticed
that in the glossary, tagbody tags can be bound. I think that this use
of ``bind'' is not supported by natural usage. Can someone point to a
naturally occurring document that uses it? (I am working on the
glossary now.) This means that an unseen go tag is a binding-error.
access-error doesn't have this problem.
I hope to make a case later that bind associates a name with an object
and to use different terminology for go tags and the like. If I
succeed, I will go for ``binding-error.''
-rpg-
∂07-Jun-89 1117 Quinquevirate-mailer 4.2
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Jun 89 11:17:19 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 607322; 7 Jun 89 14:18:45 EDT
Date: Wed, 7 Jun 89 14:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: 4.2
To: Richard P. Gabriel <rpg@lucid.com>
cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: <8906021613.AA00397@challenger>
Message-ID: <19890607182355.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Fri, 2 Jun 89 09:13:50 PDT
From: Richard P. Gabriel <rpg@lucid.com>
....
> {\function defclass\/} in the compile time environment will
> be defined in the run time environment in such a way as to have
> the same {\word superclasses\/} and compatible metaclass.
[discussion about whether the penultimate word should be "same" omitted]
[discussion about "compatible metaclass" omitted]
Maybe Moon has an opinion?
Only that the fewer mentions of metaclasses in the ANSI CL standard,
the better. It's okay to mention that metaclasses exist, i.e.
(class-of (class-of x)) doesn't signal an error. However, anything
that starts tying down the behavior of metaclasses risks being
inconsistent with whatever is eventually figured out about metaclasses.
In other words metaclasses are not ready for standardization.
If the >-quoted text above is about how a program can be structured so
that it will be guaranteed to work, rather than about what a compiler
must assume, i.e. a lower bound on working programs rather than an upper
bound, then I see no reason not to require the metaclass to be the same
for now. In some implementations and in a future language standard this
might be relaxed to also support programs where the superclasses and the
metaclass can vary. In fact I know of no CLOS implementation today that
does not support that, as a byproduct of the support for class
redefinition and for incremental addition of methods.
I have no opinion that I would care to make public about the rest of the
discussion under the subject "4.2".
∂07-Jun-89 1147 Quinquevirate-mailer Condition System Rewrite: cell-error
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Jun 89 11:47:02 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 607349; 7 Jun 89 14:48:28 EDT
Date: Wed, 7 Jun 89 14:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Condition System Rewrite: cell-error
To: Richard P. Gabriel <rpg@lucid.com>
cc: gls@Think.COM, quinquevirate@sail.stanford.edu
In-Reply-To: <8906071802.AA08181@challenger>
Message-ID: <19890607185334.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Wed, 7 Jun 89 11:02:14 PDT
From: Richard P. Gabriel <rpg@lucid.com>
I too thought ``binding-error'' was a better name, but I've noticed
that in the glossary, tagbody tags can be bound. I think that this use
of ``bind'' is not supported by natural usage. Can someone point to a
naturally occurring document that uses it? (I am working on the
glossary now.) This means that an unseen go tag is a binding-error.
access-error doesn't have this problem.
I don't think it's a problem. unseen-go-tag really is a binding-error,
and the binding-error-name function should be accessible to the condition
object, you ask me. You might get some illumination on this (or you might
not, I'm not sure I would) by thinking about a Lisp1 instead of a Lisp5,
where the equivalent of GO was performed by calling a function because
there was no separate namespace for go tags.
I hope to make a case later that bind associates a name with an object
and to use different terminology for go tags and the like. If I
succeed, I will go for ``binding-error.''
The most recent glossary I have says that binding associates a name and
an entity. The entity/object distinction is key here. "Entity"
includes both objects and some other things that can be named but are
not objects, i.e. have no physical existence that programs can
manipulate (we might have called them metaobjects if CLOS wasn't already
using that word for something else).
If "binding" refers only to associations of names and objects, then we
need another word for association of names and non-object entities
(tags, exit points, and non-class types), and perhaps a third word for
association of a name and any kind of entity. I'd rather just use the
one word "binding" for association of a name and any kind of entity, and
not have a separate word for the union of variable binding, function
binding, and class binding. But maybe you have some other words to
suggest.
∂07-Jun-89 1200 Quinquevirate-mailer re: Condition System Rewrite: cell-error
To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM
CC: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Wed, 7 Jun 89 14:53 EDT.]
The word ``entity'' bothers me. It sounds like a punt. I suspect that a
careful writer could use binding for name-object associations and other
phrases to get across that go tags and the like have certain behavior.
I'm looking at the glossary as a dictionary rather than as a source of
language. If ``binding'' is not now used for tags, I don't think we should
extend it that way. However, I await the flood of existing usage to prove
me wrong. (I exclude three sources of usage: the X3J13 spec itself and
anything written by Pitman or Jonl).
It strikes me that the key distinction between ``entity'' and ``object''
is that an entity is something that can be bound according to the extended
definition of binding. The definition of ``entity'' is simpy a list of things.
-rpg-
∂07-Jun-89 1225 Quinquevirate-mailer Condition System Rewrite
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 7 Jun 89 12:25:34 PDT
Received: from fafnir.think.com by Think.COM; Wed, 7 Jun 89 15:25:25 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 7 Jun 89 15:24:18 EDT
Received: from joplin.think.com by verdi.think.com; Wed, 7 Jun 89 15:24:16 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Wed, 7 Jun 89 15:24:13 EDT
Date: Wed, 7 Jun 89 15:24:13 EDT
Message-Id: <8906071924.AA06070@joplin.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: rpg@lucid.com, quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 7 Jun 89 13:13 EDT <19890607171336.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Subject: Condition System Rewrite
Date: Wed, 7 Jun 89 13:13 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
...
Date: Sun, 4 Jun 89 19:47:08 PDT
From: Richard P. Gabriel <rpg@lucid.com>
On further reading I see that handler-bind conditions are searched in
left-to-right order, as is handler-case. On further reflection, I
think handler-case should do this, but not handler-bind, especially
when there is the type-hierarchy-imposed order that is more
interesting than left-to-right. handler-BIND isn't especially
reminiscent of <anything>-CASE. Presumably implementations can
CLOSize conditions using multiple inheritance, which makes this
There seems to be a line missing here. I still maintain that the order
for handler bind should be the order that the programmer wrote, and not
anything derived from type hierarchy. Do you agree or disagree?
Perhaps they should be searched right-to-left, on the theory that
the *bindings* are processed left to right, and inner handlers
should be tried before outer handlers?
--Q
∂07-Jun-89 1307 Quinquevirate-mailer 4.2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jun 89 13:07:20 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA06470g; Wed, 7 Jun 89 13:05:18 PDT
Received: by challenger id AA08314g; Wed, 7 Jun 89 13:04:27 PDT
Date: Wed, 7 Jun 89 13:04:27 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906072004.AA08314@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 7 Jun 89 14:23 EDT <19890607182355.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Subject: 4.2
I agree with Moon's approach. If our strategy is to state that the
specification of compilation is a specification of a guaranteed way to
make conforming programs work correctly, but that other ways might work too,
then saying that the metaclass must be the same is the better thing. This
answers the question that ``compatible metaclass?'' asked.
-rpg-
∂08-Jun-89 0947 Quinquevirate-mailer re: Condition System Rewrite: cell-error
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 8 Jun 89 09:47:07 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 608058; 8 Jun 89 12:48:42 EDT
Date: Thu, 8 Jun 89 12:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: re: Condition System Rewrite: cell-error
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: quinquevirate@SAIL.Stanford.EDU
In-Reply-To: <ejZSF@SAIL.Stanford.EDU>
Message-ID: <19890608165343.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: 07 Jun 89 1200 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Wed, 7 Jun 89 14:53 EDT.]
The word ``entity'' bothers me. It sounds like a punt. I suspect that a
careful writer could use binding for name-object associations and other
phrases to get across that go tags and the like have certain behavior.
If the association of a name with a variable and the association of a name
with a go tag are the same kind of thing, it would be good to have a word
for that thing rather than using carefully constructed periphrastic phrases,
in my opinion. I'm not sure where the word "entity" came from, escept that
it's used this way in CLtL (it's not in the index, but see p.36 for example)
but it's probably being used consistently with its dictionary definition.
You've given me another excuse not to make any progress on rewriting section
4.1. If there is controversy on how to explain the concept of environments,
I can't make any progress on cleaning up the messy explanation that exists now.
I'm looking at the glossary as a dictionary rather than as a source of
language.
I both agree and disagree with that. On the one hand, we shouldn't be forced
by the glossary into saying something different from what we want to say. On
the other hand, once we have agreed on the glossary it seems senseless not to
use it as the source of answers to our questions about what terminology to
choose. If we base our terminology on an agreed-upon glossary, the document
seems likely to be less inconsistent. If we still haven't agreed on the
glossary I don't see how we are going to finish in time.
If ``binding'' is not now used for tags, I don't think we should
extend it that way. However, I await the flood of existing usage to prove
me wrong. (I exclude three sources of usage: the X3J13 spec itself and
anything written by Pitman or Jonl).
Since there is no consistent use of the word "binding" in the Lisp community,
our only choices are to create a consistent use or eschew the word entirely.
CLtL uses "binding" to refer only to variables. Chapter 3 uses contorted
language, including using only variables in the examples, to avoid needing
a word similar to "binding" for the other kinds of entities. The closest
it comes is to use "name" as a verb. Perhaps Guy can suggest what we should
do here.
Also CLtL (pp.36-7) seems to make a distinction between a variable
binding, which is an entity to which a variable name is bound by an
environment, and the value of a variable binding, an object associated
with that entity. Presumably that's so that we can describe what SETQ
does as changing the value of the variable binding, but not changing the
association of the name with the variable binding. This is needed to
properly describe environment sharing in lexical closures. A variable
binding is really a cell, but we're avoiding that term.
It strikes me that the key distinction between ``entity'' and ``object''
is that an entity is something that can be bound according to the extended
definition of binding. The definition of ``entity'' is simpy a list of things.
Yes. I don't see anything wrong with that.
∂08-Jun-89 1143 Quinquevirate-mailer Glossary
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Jun 89 11:43:35 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA14258g; Thu, 8 Jun 89 11:42:05 PDT
Received: by challenger id AA09463g; Thu, 8 Jun 89 11:40:58 PDT
Date: Thu, 8 Jun 89 11:40:58 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906081840.AA09463@challenger>
To: quinquevirate@SAIL.Stanford.EDU
Subject: Glossary
It seems that CLtL uses ``entity'' only in the discussion of dynamic
scope. This is a reasonable use. I think, though, that as long as it
is used only in that one place, it should not appear in the glossary
(but I'll have to check on this more). Is there any other place CLtS
(Common Lisp the Specification) that uses the term ``binding'' to
refer to anything but variable and function bindings? Kathy, perhaps you
can search the likely sections for such wording?
I both agree and disagree with that. On the one hand, we shouldn't be forced
by the glossary into saying something different from what we want to say. On
the other hand, once we have agreed on the glossary it seems senseless not to
use it as the source of answers to our questions about what terminology to
choose. If we base our terminology on an agreed-upon glossary, the document
seems likely to be less inconsistent. If we still haven't agreed on the
glossary I don't see how we are going to finish in time.
Hm, I meant to say that the glossary should reflect as best it can a
set of precise definitions of existing terminology with only a minimal
amount of terminology invention. On glancing at the glossary so far, I
see nothing major that's wrong with it (but I'm often mistaken).
I don't believe we can get the spec in good shape by June 26, but our
real deadline is the last week of July, when we need to send it to
ISO. I am now spending all my work time on the specification.
-rpg-
∂12-Jun-89 1956 Quinquevirate-mailer Glossary
To: quinquevirate@SAIL.Stanford.EDU, kmp@STONY-BROOK.SCRC.SYMBOLICS.COM
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I am about 1/2 finished with the glossary. So far I have made only
1 substantial change, which is to eliminate the term `entity'. However,
I have not, I think, changed any of the definitions that followed from it -
I merely folded in the terms where they belong.
I think that if Moon needs the term `entity' for 4.1, he can locally define
it, which is what Steele did with it.
I am working with the mass of Pitman's comments and Moon's responses, answering
question posed to me. I am adopting Pitman's proposal for dictionary-like
presentation a little more than Kathy did. I hope to be done in a day or
two (this is really tough slogging).
-rpg-
∂16-Jun-89 1331 Quinquevirate-mailer Glossary
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Jun 89 13:31:47 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA07134g; Fri, 16 Jun 89 13:29:59 PDT
Received: by challenger id AA05958g; Fri, 16 Jun 89 13:29:03 PDT
Date: Fri, 16 Jun 89 13:29:03 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906162029.AA05958@challenger>
To: quinquevirate@sail.stanford.edu
Subject: Glossary
I've mailed my draft of the glossary to Kathy for her to look at. It
was tougher than I thought it would be, but what else would you expect
from a harmless drudge? If you want to see it or use it for a section
you're working on, let me know. It is very fontful.
-rpg-
∂16-Jun-89 1421 Quinquevirate-mailer Please read
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 16 Jun 89 14:21:44 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA15386; Fri, 16 Jun 89 14:23:02 PDT
Message-Id: <8906162123.AA15386@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA15386; Fri, 16 Jun 89 14:23:02 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 16 Jun 89 09:46
To: quinquevirate@sail.stanford.edu
Subject: Please read
Following is a summary of where we are on 6/15/89. Following that is a
proposed way to present what we have done at the meeting. Later today
or Monday you will receive the source for the slides for review.
Sections that are "done":
1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 2.1, 2.2, 5.1, Glossary, macros, the-evaluator
Sections that are "almost done":
4.1, 4.2, 2.3, 2.4, 2.5
Sections left to be reviewed:
Masinter: 3.1-3.4, 5.2-5.4, PREDICATES, STRINGS, SEQUENCES, LISTS, NUMBERS,
IO, STREAMS, FILE-SYSTEM-INTERFACE, CONTROL-STRUCTURE, PROGRAM-STRUCTURE,
MISCELLANEOUS-FEATURES
RPG - 6.1, CLOS
GLS - STRUCTURES, SYMBOLS, HASHTABLES, ARRAYS, TYPES, DECLARATIONS
Moon - ERRORS, PACKAGES, CHARACTERS
For the meeting:
- Vote on CONFORMANCE-POSITION.
- Introduce a road-map to the standard.
- Outline the high points of the meaty sections that we've finished.
These include 2.2, 5.1, and the Glossary.
- Outline the high points of 4.1 and 4.2.
- Explain the schedule we're working towards. This includes an explanation
of what we plan to give to ISO and when, when we plan to send the complete
standard to X3J13, when we plan to complete collecting comments from X3J13,
and when we plan to call for a vote to send the document to public review.
I will create slides for these topics for your review before next Thursday.
I will present the information during our time slot unless any of you feel that
a section or part of a section will be sufficiently controversial that it
needs to be presented by the person who did the review/rewrite. (Examples
include 4.2 and 5.1).
kathy
∂16-Jun-89 1534 Quinquevirate-mailer schedule
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 15:34:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612331; 16 Jun 89 18:35:47 EDT
Date: Fri, 16 Jun 89 18:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: schedule
To: chapman%aitg.DEC@decwrl.dec.com
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8906162123.AA15386@decwrl.dec.com>
Message-ID: <19890616223545.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 16 Jun 89 09:46
From: chapman%aitg.DEC@decwrl.dec.com
- Explain the schedule we're working towards. This includes an explanation
of what we plan to give to ISO and when, when we plan to send the complete
standard to X3J13, when we plan to complete collecting comments from X3J13,
and when we plan to call for a vote to send the document to public review.
I don't know this information myself. What is it?
∂16-Jun-89 1608 Quinquevirate-mailer checked out as of 6/15/89
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 16 Jun 89 16:08:37 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA21713; Fri, 16 Jun 89 16:09:51 PDT
Message-Id: <8906162309.AA21713@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA21713; Fri, 16 Jun 89 16:09:51 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 16 Jun 89 09:47
To: quinquevirate@sail.stanford.edu
Subject: checked out as of 6/15/89
1.1 KC Done.
1.2 KC Updating as necessary
1.3 KC Updating as necessary
1.4 KC Updating as necessary
1.5 KC Updating as necessary
1.6 KC Updating as necessary
2.1 KC Updating as necessary
2.2 KC Done
2.3 RPG 5/5/89 Reviewing?
2.4 RPG 5/5/89 Reviewing?
2.5 RPG 5/5/89 Reviewing?
3.1 KC Moon/Masinter to review
3.2 KC Moon/Masinter to review
3.3 KC Moon/Masinter to review
3.4 KC Moon/Masinter to review
4.1 RPG 6/14/89 Updating in conjunction w/ 4.2
4.2 RPG 5/16/89 Reviewing
5.1 KC Done.
5.2 Masinter 4/7/89 Reviewing?
5.3 Masinter 4/7/89 Reviewing?
5.4 KC Masinter is to review
6.1 RPG 6/14/89 Reviewing
Glossary RPG 5/16/89 Almost done.
For all of the following "sections" that KC has,
comments from other reviewers are being inserted, but they can
be made available to the person who is to review them anytime.
Also, if you are not reviewing the parts checked out to you, you
can check them back in and I can include the compiler and character
issues in those sections.
CLOS KC RPG is to review
PREDICATES KC Masinter is to review
STRINGS KC Masinter is to review
SEQUENCES KC Masinter is to review
LISTS KC Masinter is to review
NUMBERS KC Masinter is to review
STRUCTURES KC GLS is to review
SYMBOLS KC GLS is to review
HASHTABLES KC GLS is to review
ARRAYS KC GLS is to review
TYPES KC GLS is to review
DECLARATIONS KC GLS is to review
IO KC Masinter is to review
STREAMS KC Masinter is to review
FILE KC Masinter is to review
CONTROL KC Masinter is to review
PROGRAM KC Masinter is to review
MISC KC Masinter is to review
ERRORS KC Moon is to review
MACROS KC Done
PACKAGES KC Moon is to review
CHARACTERS KC Moon is to review
EVALUATOR KC Done.
∂16-Jun-89 1627 Quinquevirate-mailer Returned mail: User unknown
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 16:27:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612375; 16 Jun 89 19:28:46 EDT
Return-path: <MAILER-DAEMON@ARGUS.STANFORD.EDU>
Received: from ARGUS.STANFORD.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 612339; 16 Jun 89 18:50:06 EDT
Received: from STONY-BROOK.SCRC.SYMBOLICS.COM by argus.Stanford.EDU with TCP; Fri, 16 Jun 89 12:42:11 PDT
Date: Fri, 16 Jun 89 12:42:11 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON@argus.Stanford.EDU>
Subject: Returned mail: User unknown
To: <Moon@stony-brook.scrc.symbolics.com>
Resent-To: quinquevirate@sail.stanford.edu
Resent-From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 16 Jun 89 19:29 EDT
Resent-Message-ID: <19890616232912.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Resent-Comments: Send it again with my damn eyes open and the typo in the mailing
list name fixed. Geez, Dave.
----- Transcript of session follows -----
>>> RCPT To:<qinquevirate@sail.stanford.edu>
<<< 550 I don't know anybody named qinquevirate
550 <qinquevirate@SAIL.STANFORD.EDU>... User unknown
----- Unsent message follows -----
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612139; 16 Jun 89 15:57:31 EDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 606630; 6 Jun 89 12:09:03 EDT
Date: Tue, 6 Jun 1989, 12:04-EDT
From: <Postmaster@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Unable to deliver letter
Message-Id: <19890606160459.3.FILE-SERVER@STONY-BROOK.SCRC.Symbolics.COM>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Resent-To: RPG@sail.stanford.edu, GLS@think.com, Masinter.pa@Xerox.com,
Moon@STONY-BROOK.SCRC.Symbolics.COM
Resent-From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Tue, 6 Jun 89 12:14 EDT
Resent-Message-Id: <19890606161412.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Resent-Comments: OK, where did the mailing list go?
Resent-To: qinquevirate@SAIL.STANFORD.EDU
Resent-From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 16 Jun 89 15:57 EDT
Resent-Message-Id: <19890616195736.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Resent-Comments: This message was never answered, but later messages to qinquevirate
got through, so I guess it must have been repaired at some point.
Unable to deliver letter to the following recipient:
qinquevirate@SAIL.STANFORD.EDU:
SMTP error from host SAIL.STANFORD.EDU:
Command issued: RCPT To:<qinquevirate@SAIL.STANFORD.EDU>
Expected replies: 250, 251
Received reply: 550 I don't know anybody named qinquevirate
----- Text of letter follows -----
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 606609; 6 Jun 89 11:41:35 EDT
Date: Tue, 6 Jun 89 11:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: miscellaneous questions
To: chapman%aitg.DEC@decwrl.dec.com
cc: qinquevirate@sail.stanford.edu
In-Reply-To: <8906051937.AA14818@decwrl.dec.com>
Message-ID: <19890606154646.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: 5 Jun 89 14:03
From: chapman%aitg.DEC@decwrl.dec.com
re: COPY-SEQ
Did you receive any comments about which of these interpretations
is the preferred?
There have been no replies to that message I sent on 30 May.
%% Moon's suggested interpretation follows:
For {\function nreverse\/}, if
{\arg sequence\/} is a {\datatype vector\/}, the result is a
{\datatype vector\/} that has the same
{\function array-element-type\/} as {\arg sequence\/}.
The result might or might not be simple, and
might or might not be {\function eq\/}
to {\arg sequence\/}.
- or -
%% Another possible interpretation:
%% The result might or might not be {\function eq\/} to {\arg sequence\/}.
%% If the result is a {\datatype vector\/} that is not {\function eq\/}
%% to {\arg sequence\/}, the result is a freshly-allocated {\datatype
%% simple-array\/} of rank one.
If {\arg sequence\/} is a {\datatype list\/}, the result is a
{\datatype list\/}.
%% End Moon's suggested interpretation.
I now think the alternate interpretation is better, because it specifies
more, and what it specifies is not harmful. Specifically it requires that
if the result is a vector, it is either eq to the argument or a freshly
allocated simple vector. The only problem with this is that if the result
is a list, we cannot say that, since the result could also be eq to any
cons of the argument, or could be a freshly allocated cons whose cdr chain
shares structure with the argument in a complicated way.
Thus:
For {\function nreverse\/}, if
{\arg sequence\/} is a {\datatype vector\/}, the result is a
{\datatype vector\/} that has the same
{\function array-element-type\/} as {\arg sequence\/}.
If {\arg sequence\/} is a {\datatype list\/}, the result is a
{\datatype list\/}.
The result might or might not be {\function eq\/} to {\arg sequence\/}.
If the result is a {\datatype vector\/} that is not {\function eq\/}
to {\arg sequence\/}, the result is a freshly-allocated {\datatype
simple-array\/} of rank one.
∂21-Jun-89 0339 Quinquevirate-mailer slides for meeting
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Jun 89 03:39:11 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA21386; Wed, 21 Jun 89 00:07:21 PDT
Message-Id: <8906210707.AA21386@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for sandra%defun@cs.utah.edu; id AA21386; Wed, 21 Jun 89 00:07:21 PDT
From: chapman@aitg.enet.dec.com
Date: 21 Jun 89 02:52
To: quinquevirate@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: slides for meeting
The following slides are my proposed presentation for the meeting.
Our time slot is Wednesday. Handouts to everyone will include the
two issues to be voted on and the sections that are "done" and
"almost done" that I listed for you last week. So as the following
slides are being presented, the audience can be flipping through
the relevant part of the standard.
It seems important to get the committee to agree that the standard is
ready to be reviewed. This is the first step to voting it out of
X3J13. The idea of this presentation is to make the massive document
that is the standard easier to navigate for the first-time reader.
Please change these slides to your liking, but I'll need the
changes no later than Thursday midday (Eastern time). Sorry for
such a short review time. I was out on Monday and so had some
catching up to do.
Thanks for your help.
kathy
**********************************************************************
\documentstyle[overhead]{article}
\begin{document}
\TITLEFONT{\bsf}
\SLIDETITLE{\it Standard Status, June, 1989}
\SLIDEFOOT{\hfill \Digital}
\VSLIDE{Working Draft American National Standard for
Information Systems - Programming Language Common Lisp }
\begin{center}
June 28, 1989
\end{center}
\vfill
\VSLIDE{Overview}
\begin{itemize}
\item CONFORMANCE-POSITION and EXTRA-RETURN-VALUES
\item Road-map to the standard
\item Summary of sections 2.2, 5.1, and the Glossary
\item Outline of sections 4.1 and 4.2
\item The schedule
\end{itemize}
\VSLIDE{CONFORMANCE-POSITION and EXTRA-RETURN-VALUES}
\begin{itemize}
\item Vote
\end{itemize}
\VSLIDE{Road-map to the standard}
\begin{itemize}
\item Important fonts for navigation are the glossary font
and the data type font
\item To understand a ``defined name''
\begin{itemize}
\item Read section 6.1
\item Locate defined name description in TOC or index
\item Read all associated ``See Also'' references, especially
the section references
\end{itemize}
\item To understand a concept
\begin{itemize}
\item Concepts apply to categories of functions
\item Concepts currently defined: types, reading, evaluation, compilation,
conditions, object system concepts, I/O, generalized reference
\item Concepts are explained in chapters 2-5:
Chapter 2---types and object system concepts; Chapter 3---reading;
Chapter 4---evaluation, compilation and condition system concepts;
Chapter 5---conditions, I/O, generalized reference
\end{itemize}
\end{itemize}
%% David, would you like to present this one?
\VSLIDE{Summary of section 2.2}
\begin{itemize}
\item Similar to CLtL chapters 2 and 4, heavily modified by issues
\item Data type definitions: includes all CLOS and condition types
described in order of appearance in the diagram.
\item Data type hierarchy
%% All four hierarchy charts will be presented
\item Relationships between types
\item Rules that affect creation of new types
\item Type specifiers
%% Type specifier syntax diagrams will be presented
\item Controversial interpretations?
\end{itemize}
%% Dick, would you like to present this one?
\VSLIDE{Summary of section 5.1}
\begin{itemize}
\item Follows Condition System rev. 18 adopted by X3J13 last year
\item Error terms in section 1.4
\item Condition type hierarchy in section 2.2
\item Definition of terminology used in conjunction with conditions:
situation, error, signalling, handler
\item Summary of condition creation: functions used and their arguments
\item Restarts: description and semantics of active restarts
\item Printing: report methods, limitations
\item Assertions: description and list of applicable defined names
\item Debugging: list of applicable utilities
\end{itemize}
%% Dick, would you like to present this one?
\VSLIDE{Summary of the Glossary}
\begin{itemize}
\item Formatted dictionary-style
\item Contains definitions for object system terms since their
definition and use are spread over multiple chapters
\item Defines idiomatic, computer, and mathematical usage where applicable
\item Some defined terms are: accessible, binding, bound declaration,
control form, dynamic environment, environment, establish, evaluation,
exit point, free declaration, keyword, lambda list keyword, lexical closure,
mapping, name, top level form
\end{itemize}
%% David, would you like to present this section?
\VSLIDE{Outline of section 4.1}
\begin{itemize}
\item New organization of CLtL material prefaced by an evaluation
``algorithm''
%% Eval model diagram presented here
\item First the model is presented in outline form
\item Then form processing is described
\item There are special sections on macros, special forms, functions,
variables, generic functions, methods, lambda expressions, and closures
\end{itemize}
%% Sandra, would you mind talking about this section?
\VSLIDE{Outline of section 4.2}
\begin{itemize}
\item Mostly new material generated by the compiler committee as
a result of passed and pending issues
\item Compilation semantics
\item A model of how compile-file works
\item Compiler/loader interface
\item Information about the compiler's interpretation of constants
\item Error handling
\end{itemize}
\VSLIDE{The schedule}
\begin{itemize}
\item To ISO: Working draft as of the last week in July. Drafting committee
is planning to be done with their review/rewrite by then.
\item To X3J13: Complete document will be made available for review right
after the ISO submission. Reviewers should understand what they are reviewing
for.
\item End of comment period: Comments should be received no later than mid-
October.
\item Vote to send the document to public review: At November, 1989, meeting.
\end{itemize}
\end{document}
∂21-Jun-89 1507 Quinquevirate-mailer Agenda for June meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:07:04 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 614619; 21 Jun 89 15:45:49 EDT
Date: Wed, 21 Jun 89 15:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Agenda for June meeting
To: Quinquevirate@sail.stanford.edu, JLZ@Lucid.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Sandra%defun@cs.utah.edu
Message-ID: <19890621194359.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
I have looked over the pending cleanup issues and assigned times,
based on how much time I thought it would take and for some issues,
the earliest time I thought the discussion could be cut off. The
result is that the cleanup committee will need 4 hours to do what
absolutely has to be done, or 6 hours 15 minutes to do everything
that might want to be done (assuming we keep moving along briskly).
How shall we fit this into the agenda?
Details:
This is cleanup issues only, not compiler or editorial issues.
Times given for each section are first the time assuming all potentially
tabled issues are excluded, then the total time including all issues.
These times assume we move along briskly but do include some overhead.
Miscellaneous Issues carried over from previous meeting: (1:45, 2:30)
ADJUST-ARRAY-NOT-ADJUSTABLE 10 minutes
DYNAMIC-EXTENT-FUNCTION 5 minutes
FORMAT-ROUNDING 5 minutes
HASH-TABLE-PRINTED-REPRESENTATION 10 minutes (or has this been tabled?)
HASH-TABLE-SIZE 5 minutes
IGNORE-VARIABLE 5 minutes
LOAD-TRUENAME 5 minutes
MACRO-CACHING 5 minutes
PRETTY-PRINT-INTERFACE 10 minutes
PRINT-CASE-PRINT-ESCAPE-INTERACTION 5 minutes
PRINT-CIRCLE-SHARED 5 minutes (or has this been tabled?)
READ-CASE-SENSITIVITY 10 minutes
SETF-MULTIPLE-STORE-VARIABLES 5 minutes
STRUCTURE-INFO 5 minutes (or has this been tabled?)
SYNTACTIC-ENVIRONMENT-ACCESS 10 minutes (but I think this is in the compiler comm)
TAIL-RECURSION-OPTIMIZATION 10 minutes (or has this been tabled?)
THE-AMBIGUITY 5 minutes
UNDEFINED-VARIABLES-AND-FUNCTIONS 10 minutes
WITH-OPEN-FILE-DOES-NOT-EXIST 5 minutes
Error Issues: (0:30)
CONDITION-RESTARTS 5 minutes??
DELETE-FILE-NONEXISTENT 5 minutes but maybe this has been tabled?
ERROR-CHECKING-IN-NUMBERS-CHAPTER 5 minutes
ERROR-MACRO-MULTIPLE-EVALUATION 5 minutes
Pathname Issues: (1:30, 2:00)
PATHNAME-CANONICAL-TYPE 10 minutes (or is this tabled?)
PATHNAME-COMPONENT-CASE 10 minutes
PATHNAME-COMPONENT-VALUE 5 minutes
PATHNAME-EXTENSIONS 5 minutes
PATHNAME-LOGICAL 15 minutes
PATHNAME-PRINT-READ 10 minutes
PATHNAME-SUBDIRECTORY-LIST 5 minutes
PATHNAME-SYNTAX-ERROR-TIME 5 minutes
PATHNAME-SYSTEM-TYPE 5 minutes
PATHNAME-WILD 10 minutes
TRUENAME-SYNTAX-ONLY 10 minutes (or is this tabled?)
New Issues: (0:45)
BIT-ARRAY-FUNCTIONS 10 minutes
DATA-IO 5 minutes
FLOAT-UNDERFLOW 5 minutes
INTERACTIVE-FUNCTIONS 5 minutes
MAP-INTO 5 minutes
STRING-COERCION 5 minutes
Failed Issues that Might Rise Again: (0:30)
DEFINE-OPTIMIZER 5 minutes
PROCLAIM-LEXICAL 15 minutes
Grand total time
Minimum 3 hours 45 minutes, omitting all new or potentially tabled issued
Maximum 6 hours 15 minutes
∂21-Jun-89 1506 Quinquevirate-mailer Re: Agenda for June meeting
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:06:33 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA02241; Wed, 21 Jun 89 16:06:56 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA01776; Wed, 21 Jun 89 16:06:47 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906212206.AA01776@defun.utah.edu>
Date: Wed, 21 Jun 89 16:06:46 MDT
Subject: Re: Agenda for June meeting
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Quinquevirate@sail.stanford.edu, JLZ@Lucid.com,
KMP@STONY-BROOK.SCRC.Symbolics.COM, Sandra%defun@cs.utah.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Jun 89 15:43 EDT
Although I requested a half day for compiler, I certainly hope it
doesn't take us that long. (I was only reacting to people who told me
last time that I should have asked for a bigger chunk of time.) We
have only a handful of issues and all of them are leftovers from the
last meeting. If we rush we could probably get through them all in an
hour.
You have a few compiler issues mixed in with the cleanup ones on your
list. These are:
> Miscellaneous Issues carried over from previous meeting: (1:45, 2:30)
> MACRO-CACHING 5 minutes
> SYNTACTIC-ENVIRONMENT-ACCESS 10 minutes (but I think this is in the compiler comm)
>
> Failed Issues that Might Rise Again: (0:30)
> DEFINE-OPTIMIZER 5 minutes
I don't think that I've ever seen writeups on some of the cleanup
issues that you had marked as being leftovers from the last meeting.
Probably the safest procedure would be to distribute copies of all the
issues on the list, even the ones that might already have been
distributed at the last meeting.
-Sandra
-------
∂21-Jun-89 1509 Quinquevirate-mailer slides for meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:07:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614671; 21 Jun 89 16:34:50 EDT
Date: Wed, 21 Jun 89 16:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: slides for meeting
To: chapman@aitg.enet.dec.com
cc: quinquevirate@sail.stanford.edu, sandra%defun@cs.utah.edu
In-Reply-To: <8906210707.AA21386@decwrl.dec.com>
Message-ID: <19890621203522.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
The slides look okay to me without any changes.
I don't think it's necessary for me to present section 2.2, I think you
can do fine. I also think we should not go into much detail here.
Flash up the charts and diagrams but don't try to explain them and don't
leave them up long enough for the audience to read carefully all the way
through them. We're not trying to convince people this section is
technically correct, we're just giving them an overview of how it's
structured. Right? You might want to talk briefly about how and why
the structure differs from CLtL.
The same goes for the other sections presented in detail. I don't think
we want to take the time to try to convince the audience that what was
written down is technically correct. We just want to present the
structure of the text and how it differs from CLtL. For a suggestion
for where we should spend time, see below.
I don't think I can present section 4.1. I once offered to rewrite it,
but I have not done so, and I'm not really all that familiar with the
section. Last I heard RPG was going to work on it, but I don't know
that he has started to do so.
It seems important to get the committee to agree that the standard is
ready to be reviewed. This is the first step to voting it out of
X3J13.
I agree that it's important. At first I thought you meant "go out for
public review" and I really would not agree that it's ready for that
myself. After reading the slides, I see that you meant review within
X3J13 between end of July and mid-October, a whole different story from
public review. Be sure to be clear about this when presenting!
I think the most important thing to spend time on here, aside from
building concensus that we ought to review the document, which I don't
think will be at all difficult, is the review process. The drafting
committee has not discussed this at all, at least not recently. The
review process adopted in March was not followed (as it was determined
to be unrealistic). As you say, "Reviewers should understand what they
are reviewing for." I'd like to see us come out of the June meeting
with not only that bald statement, but a specific statement of what
they are reviewing for, and a belief that the members of X3J13 both
endorse and, more importantly, understand that statement. Actually
identifying the individuals who will review can come later. Do you
have specific review goals already in mind? If not, should the
drafting committee assemble a statement of goals? Just to start
things off, I will suggest (in decreasing order of priority):
1. Faithfulness to the decisions made by X3J13
2. Lack of ambiguity
3. Lack of technical inconsistency
4. Consistency of presentation, typos, grammar, spelling
5. Clarity of presentation
6. Niceness of Common Lisp as a programming language
Point 6 is mentioned really as an opportunity to say that that
is NOT a goal of this review process, a stronger statement than
saying that it is the goal with the lowest priority.
Point 3 is given lower priority than point 2 because inconsistency can
be recognized by the reader, whereas ambiguity may go unrecognized and
simply produce different thoughts in different readers. Points 1, 2,
and 3 are necessary for the document to be used in the way it was
intended. Points 4 and 5 simply make the document easier to use, so
they get lower priority. The relative order of 4 and 5 is debatable.
I believe I got the relative order of points 1, 2, and 3 correct. Of
course the decisions made by X3J13 are certainly ambiguous and probably
inconsistent, so we can't say that goal 1 takes absolute priority over
goals 2 and 3. But I think we have to put goal 1 first or we will have
chaos, i.e. no basis for making decisions among conflicting reviewers.
Is the above controversial within the gang of six?
Should all reviewers review with the same goals, or should goals
be parcelled out to different individuals?
The other part of the process is finding a way to get people to
actually read the stuff, and finding a way to make sure that
different people read different parts so all of it gets read by
someone (or several people). I still don't have any ideas for
how to accomplish that.
∂21-Jun-89 1510 Quinquevirate-mailer Agenda for June meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:07:28 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 614677; 21 Jun 89 16:38:53 EDT
Date: Wed, 21 Jun 89 16:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Agenda for June meeting
To: Quinquevirate@sail.stanford.edu, JLZ@Lucid.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Sandra%defun@cs.utah.edu
Message-ID: <19890621203709.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Can we move the characters subcommittee to the first day, which is almost
empty? Or do they, like the cleanup and compiler committees, have handouts
which they expect people to have read before the committee's time, so that
they can't go on the first day? I'd also think about moving the drafting
committee to the first day, because it should be done when people are not
tired, and it does not require as much preparation on the part of the
audience.
∂21-Jun-89 1527 Quinquevirate-mailer Re: Agenda for June meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:26:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614799; 21 Jun 89 18:28:26 EDT
Date: Wed, 21 Jun 89 18:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Agenda for June meeting
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Quinquevirate@sail.stanford.edu, JLZ@Lucid.com, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8906212206.AA01776@defun.utah.edu>
Message-ID: <19890621222905.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 21 Jun 89 16:06:46 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Although I requested a half day for compiler, I certainly hope it
doesn't take us that long. (I was only reacting to people who told me
last time that I should have asked for a bigger chunk of time.) We
have only a handful of issues and all of them are leftovers from the
last meeting. If we rush we could probably get through them all in an
hour.
I don't believe you can get through them that fast, some will probably
provoke a lot of discussion and you probably won't be willing to tell
people to shut up the instant they open their mouths. I would allow
an average of 15 minutes an issue (as ten minutes of scheduled time
per issue, plus the rest to allow for things running over and other
unscheduled overhead).
You have a few compiler issues mixed in with the cleanup ones on your
list. These are:
> Miscellaneous Issues carried over from previous meeting: (1:45, 2:30)
> MACRO-CACHING 5 minutes
> SYNTACTIC-ENVIRONMENT-ACCESS 10 minutes (but I think this is in the compiler comm)
>
> Failed Issues that Might Rise Again: (0:30)
> DEFINE-OPTIMIZER 5 minutes
Thanks, I'll leave these to the compiler committee.
I don't think that I've ever seen writeups on some of the cleanup
issues that you had marked as being leftovers from the last meeting.
Probably the safest procedure would be to distribute copies of all the
issues on the list, even the ones that might already have been
distributed at the last meeting.
Good plan. Now all we have to do is figure out who's responsible for
making the copies.
∂21-Jun-89 1538 Quinquevirate-mailer Re: slides for meeting
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:38:44 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03406; Wed, 21 Jun 89 16:38:59 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA01829; Wed, 21 Jun 89 16:38:54 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906212238.AA01829@defun.utah.edu>
Date: Wed, 21 Jun 89 16:38:53 MDT
Subject: Re: slides for meeting
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: chapman@aitg.enet.dec.com, quinquevirate@sail.stanford.edu,
sandra%defun@cs.utah.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Jun 89 16:35 EDT
> Date: Wed, 21 Jun 89 16:35 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> I think the most important thing to spend time on here, aside from
> building concensus that we ought to review the document, which I don't
> think will be at all difficult, is the review process. The drafting
> committee has not discussed this at all, at least not recently. The
> review process adopted in March was not followed (as it was determined
> to be unrealistic).
I agree. I know that the thing I want to know about is the new
timetable and the process that will be followed to review and actually
decide that the document is ready for external review. Most people
apparently never received the message that Kathy sent out explaining
that the schedule from the last meeting was being abandoned, and I
expect there will be a lot of questions about what has been happening
in the meantime. In fact, I would suggest dealing with this at the
very beginning of the presentation instead of saving it for last.
> 1. Faithfulness to the decisions made by X3J13
> 2. Lack of ambiguity
> 3. Lack of technical inconsistency
> 4. Consistency of presentation, typos, grammar, spelling
> 5. Clarity of presentation
> 6. Niceness of Common Lisp as a programming language
This looks reasonable to me.
> The other part of the process is finding a way to get people to
> actually read the stuff, and finding a way to make sure that
> different people read different parts so all of it gets read by
> someone (or several people). I still don't have any ideas for
> how to accomplish that.
How about bribing some poor graduate students to do it? :-)
Seriously, I was planning to coerce some other people here at Utah
into helping out with the review. I talked about it before with Bob
Kessler and he said he was willing to give people independent study
credits for this, which might induce them to work harder on it.
-Sandra
-------
∂21-Jun-89 1546 Quinquevirate-mailer Re: slides for meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:46:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614825; 21 Jun 89 18:47:34 EDT
Date: Wed, 21 Jun 89 18:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: slides for meeting
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: chapman@aitg.enet.dec.com, quinquevirate@sail.stanford.edu
In-Reply-To: <8906212238.AA01829@defun.utah.edu>
Message-ID: <19890621224808.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 21 Jun 89 16:38:53 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> The other part of the process is finding a way to get people to
> actually read the stuff, and finding a way to make sure that
> different people read different parts so all of it gets read by
> someone (or several people). I still don't have any ideas for
> how to accomplish that.
How about bribing some poor graduate students to do it? :-)
Seriously, I was planning to coerce some other people here at Utah
into helping out with the review. I talked about it before with Bob
Kessler and he said he was willing to give people independent study
credits for this, which might induce them to work harder on it.
That's a good idea. Of course, it wouldn't work to have only poor
graduate students reading it. It's got to be read by people who are
highly knowledgeable about Common Lisp and by people who are serious
Common Lisp users, also.
∂21-Jun-89 1556 Quinquevirate-mailer Re: slides for meeting
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:56:09 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03867; Wed, 21 Jun 89 16:56:07 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA01885; Wed, 21 Jun 89 16:56:04 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906212256.AA01885@defun.utah.edu>
Date: Wed, 21 Jun 89 16:56:03 MDT
Subject: Re: slides for meeting
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, chapman@aitg.enet.dec.com,
quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Jun 89 18:48 EDT
> That's a good idea. Of course, it wouldn't work to have only poor
> graduate students reading it. It's got to be read by people who are
> highly knowledgeable about Common Lisp and by people who are serious
> Common Lisp users, also.
Right. The people I had in mind are the Utah CL implementors, some of
whom are fairly wizardly. I'm the only one here who has really been
following what X3J13 has been up to in much detail, though, so they
would have to concentrate on other aspects of the document.
-Sandra
-------
∂21-Jun-89 1622 Quinquevirate-mailer 4.2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Jun 89 16:21:58 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA01607g; Wed, 21 Jun 89 16:20:05 PDT
Received: by challenger id AA16814g; Wed, 21 Jun 89 16:19:07 PDT
Date: Wed, 21 Jun 89 16:19:07 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906212319.AA16814@challenger>
To: quinquevirate@sail.stanford.edu
Subject: 4.2
I am completing my second draft of 4.2 (compilation). I feel pretty
uncertain about it. The more I worked on the original, the more it
seemed to leave unsaid or implied. I've tried to fill in those unsaid
things, but I fear I said to much or too little or simply mistakes.
But, I didn't increase its length! I will have Dussud and Benson
review it, but I think you folks will have to look at it (I will
netmail it before friday so you can bring it on the plane).
-rpg-
∂21-Jun-89 1629 Quinquevirate-mailer 4.2
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 16:29:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614887; 21 Jun 89 19:31:18 EDT
Date: Wed, 21 Jun 89 19:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: 4.2
To: Richard P. Gabriel <rpg@lucid.com>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8906212319.AA16814@challenger>
Message-ID: <19890621233153.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 21 Jun 89 16:19:07 PDT
From: Richard P. Gabriel <rpg@lucid.com>
I am completing my second draft of 4.2 (compilation). I feel pretty
uncertain about it. The more I worked on the original, the more it
seemed to leave unsaid or implied. I've tried to fill in those unsaid
things, but I fear I said to much or too little or simply mistakes.
But, I didn't increase its length! I will have Dussud and Benson
review it, but I think you folks will have to look at it (I will
netmail it before friday so you can bring it on the plane).
Okay.
∂22-Jun-89 0957 Quinquevirate-mailer re: agenda
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 22 Jun 89 09:57:13 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA11355; Thu, 22 Jun 89 09:58:40 PDT
Message-Id: <8906221658.AA11355@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA11355; Thu, 22 Jun 89 09:58:40 PDT
From: chapman@aitg.enet.dec.com
Date: 22 Jun 89 12:56
To: quinquevirate@sail.stanford.edu, jlz@lucid.com,
kmp@stony-brook.scrc.symbolics.com, sandra%defun@cs.utah.edu
Subject: re: agenda
>Can we move the characters subcommittee to the first day, which is almost
>empty? Or do they, like the cleanup and compiler committees, have handouts
>which they expect people to have read before the committee's time, so that
>they can't go on the first day? I'd also think about moving the drafting
>committee to the first day, because it should be done when people are not
>tired, and it does not require as much preparation on the part of the
>audience.
The only reason the drafting committee is set for Wednesday is because
the copies of the handouts presumably won't be available by Monday or
Tuesday. Lucid should have received them this morning. If they actually
got there, and if Lucid can get at least the small stack copied by
Monday, Monday is fine with me.
kathy
∂22-Jun-89 1547 Quinquevirate-mailer 4.2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Jun 89 15:47:28 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA07994g; Thu, 22 Jun 89 15:45:19 PDT
Received: by challenger id AA02743g; Thu, 22 Jun 89 15:46:56 PDT
Date: Thu, 22 Jun 89 15:46:56 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8906222246.AA02743@challenger>
To: quinquevirate@sail.stanford.edu
Subject: 4.2
Here is my current draft of 4.2. [Moon: I asked you some questions
about ``compilation environment'' which is unrelated to what is in
this draft, so don't look for it.]
*********************************************************************
\input macros2
\beginChapter 4.{Working Draft American National Standard
for Information Systems---Programming Language Common Lisp}%
{Introduction}{Introduction}
Editors:
Revision: \rev
\endTitlePage
%% Compilation
\beginsubSection{Introduction}
Execution of code can be accomplished by a variety of means ranging
from direct interpretation of the list structure representing a
program through compilation to machine code. An evaluator
implementation can be based on any of these strategies. The term
{\word implicit compilation\/} refers to compilation performed during
evaluation. The compiler is a utility that translates code into an
implementation-dependent form that might be represented or executed
efficiently.
Conforming code must be structured so that its results and observable
side effects will be the same whether or not implicit compilation
takes place.
% References:
% CLtL page 143 (next to last paragraph)
% CLtL page 321 (second paragraph)
%[rpg: CLtL page 438]
The nature of the processing performed during compilation is discussed
in ``Compilation Semantics''. Following ``Compilation Semantics'' is
a discussion of the behavior of {\function compile-file\/} and the
interface between {\function compile-file\/} and {\function load\/}.
\endsubSection%{Introduction}
\beginsubSection{Terminology}
% Reference: Issue CONSTANT-COMPILABLE-TYPES
The following terminology is used in this section.
The term {\word constant\/} refers to a quoted or self-evaluating
constant or an {\word object\/} that is a substructure of such a
constant, not a named {\tt (defconstant)\/} constant. See
``Constants''.
The term {\word source code\/} refers to {\word objects\/}
representing programs suitable for evaluation, such as {\word
objects\/} created by {\function read} or by macro expansion.
{\function compile-file} is not required to create such {\word
objects\/} nor to invoke {\function read}.
The term {\word compiled code\/} is used to refer to {\word objects\/}
representing compiled programs, such as {\word objects\/} constructed
by {\function load\/} when applied to a file created by {\function
compile-file\/}.
The term {\word coalesce\/} is defined as follows. Suppose {\tt A\/}
and {\tt B\/} are two quoted {\word objects\/} defined as quoted
constants in the source code, and that {\tt A'\/} and {\tt B'\/} are
the corresponding {\word objects\/} in the compiled code. If {\tt
A'\/} and {\tt B'\/} are {\function eql\/} but {\tt A\/} and {\tt B\/}
are not {\function eql\/}, then it is said that {\tt A\/} and {\tt
B\/} have been coalesced by the compiler.
Three different {\word environments\/} relevant to compilation are
distinguished: the {\word compilation environment\/}, the {\word
evaluation environment\/}, and the {\word run time environment\/}. The
{\word compilation environment\/} is maintained by the compiler and is
used to hold definitions to be used by the compiler; the compilation
environment might be separate from the {\word evaluation
environment\/}. The {\word evaluation environment\/} is the run time
{\word environment\/} of the Lisp image from which the compiler was
invoked. The {\word run time environment\/} is the {\word
environment\/} in which the program being compiled will be executed.
It is permitted to implement the compilation environment as the
evaluation environment or as part of it.
The term {\word minimal compilation\/} refers to actions the compiler
must take at compile time. These actions will be specified later.
The term {\word to process\/} refers to determining the time of
evaluation for a {\word form\/}, possibly evaluating that {\word
form\/} (if required), and performing minimal compilation.
The term {\word further compilation\/} refers to compilation beyond
minimal compilation. That is, processing does not imply complete
compilation. Further compilation is permitted to take place at run
time.
The term {\word compile time\/} refers to the duration of time that
the compiler is processing source code. At compile time, only the
compilation and evaluation {\word environments\/} are available.
The term {\word compile time definition\/} refers a definition in the
compilation environment. For example, when compiling a file, the
definition of a function must be retained in the compilation
environment if it is declared or proclaimed {\tt inline}. This
definition might not be available in the evaluation environment.
The term {\word run time\/} refers to the duration of time that the
loader is loading compiled code or compiled code is being executed.
At run time, only the run time {\word environment\/} is available.
The term {\word run time definition\/} refers to a definition in the
run time environment.
The term {\word run-time compiler\/} refers to {\function compile\/}
or implicit compilation, for which the compilation and run time {\word
environments\/} are maintained in the same Lisp (note that in this
case the run time and evaluation {\word environments\/} are the same).
The term {\word compiler\/} refers to both the run-time compiler and
{\function compile-file\/}.
\endsubSection%{Terminology}
\beginsubSection{Compilation Semantics}
% References:
% Issue COMPILE-ENVIRONMENT-CONSISTENCY [pending]
% Issue COMPILED-FUNCTION-REQUIREMENTS [pending]
% The material in this section will have to be updated to reflect further
% changes to these issues.
Conceptually, compilation is a process that traverses code, performs
certain kinds of syntactic and semantic analyses using information
(such as proclamations and {\word macro\/} definitions present in the
compile time {\word environment\/}), and produces modified code.
The compiler must perform the following actions, referred to as {\word
minimal compilation\/}:
\beginlist
\itemitem{\bull} All {\word macro\/} calls appearing as code
lexically within the code being compiled must be expanded at compile
time in such a way that they will not be expanded again at run time.
{\function macrolet\/} and {\function symbol-macrolet\/} are replaced
by {\word forms\/} corresponding to their bodies in which calls to
local {\word macros\/} are replaced by their expansions.
\itemitem{\bull}
The compiler must process {\function load-time-value\/} forms that
appear lexically within the program being compiled. In the case of
{\function compile\/} the {\function load-time-value\/} form will be
evaluated at compile time, and its result will be treated as a
constant at run time. In the case of {\function compile-file\/}, the
{\function load-time-value\/} form will be evaluated at load time.
\endlist
Additional constraints about the consistency of the compilation and
run time environments imply additional semantic constraints on
conforming programs that are intended to be compiled. Conforming
programs obeying these constraints will have the same behavior whether
evaluated or compiled, and may be more portable. Some implementations
might impose looser constraints or no such constraints at all.
Except where noted, when a compile time and a run time definition are
different, an error of type {\datatype error\/} might be signalled.
In this case, it is implementation-dependent which definition will
prevail within the compiled code.
The following are the aforementioned semantic constraints:
\beginlist
\itemitem{\bull} Any {\word form\/} that is a {\datatype list\/} beginning
with a {\datatype symbol\/} that does not name a defined {\word
macro\/} or {\word special form\/} is a function call. (This implies
that {\function setf\/} methods must be available at compile time.)
\itemitem{\bull} The definition of a function that is defined and
declared or proclaimed {\tt inline} in the compilation {\word
environment\/} will be retained at run time.
\itemitem{\bull} Within a named function, a recursive call to a
function of the same name refers to the same function, unless that
function has been declared {\tt notinline}.
\itemitem{\bull} A call to a named function that is defined in the
same file refers to that function, unless that function has been
declared {\tt notinline}. The consequences are unspecified if
functions are redefined individually at run time or multiply defined
in the same file.
\itemitem{\bull} The argument syntax and number of return values for
all built-in Common Lisp functions will be the same at run time as at
compile time. All built-in Common Lisp functions are proclaimed {\tt
inline}.
\itemitem{\bull} The argument syntax and number of return values for
all functions whose {\tt ftype\/} was declared at compile time will
remain the same at run time.
% Reference: CLtL page 69
\itemitem{\bull} Constants defined with {\function defconstant\/} in
the compilation {\word environment\/} will retain the same value at
run time. A reference to the name of a constant in source code is
equivalent to a reference to an {\word object\/} {\function eql\/} to
the value of the constant.
% The following paragraph from issue COMPILE-ENVIRONMENT-CONSISTENCY
% seems likely to change:
\itemitem{\bull} Type definitions made with {\function deftype\/} or
{\function defstruct\/} in the compilation {\word environment\/} will
retain the same definition at run time. Classes defined by {\function
defclass\/} in the compilation {\word environment\/} will be defined
at run time to have the same {\word superclasses\/} and same {\word
metaclass\/}.
This implies that {\word subtype/supertype\/} relationships of type
specifiers will not change between compile time and run time. (Note
that it is permissible for an unknown {\word type\/} to appear in a
declaration at compile time, though a warning might be emitted in such
a case.)
% Ref: CLtL page 153
\itemitem{\bull} Type declarations present in the compilation {\word
environment\/} accurately describe the values of the corresponding
variables and functions at run time; otherwise, the run time behavior
of the program is undefined.
\itemitem{\bull} A {\word function\/} defined in the
evaluation {\word environment\/} might have a different definition or
a different {\word signature\/} at run time, except in the situations
explicitly listed above.
\endlist
Conforming programs should not be written using any additional
assumptions about consistency between the compilation and run time
{\word environments\/}.
The presence of a call to a {\word function\/} that is not defined at
compile time will not cause an error to be signalled at compile time.
\endsubSection%
\beginsubSection{File Compilation}
The function {\function compile-file\/} performs compilation of {\word
forms\/} in a file following the rules specified in ``Compilation
Semantics'', and produces an output file that can be loaded with
{\function load\/}.
Normally, the top-level forms appearing in a file compiled with
{\function compile-file\/} are executed only when the resulting
compiled file is loaded, and not when the file is compiled. However,
some forms in the file must be evaluated at compile time so the
remainder of the file can be be read and compiled correctly.
The special form {\function eval-when\/} can be used to control
whether a {\word top-level\/} form is evaluated at compile time, load
time, or both. It is possible to specify any of three situations with
{\function eval-when}, denoted by the symbols {\tt :compile-toplevel},
{\tt :load-toplevel}, and {\tt :execute}. For toplevel {\function
eval-when\/} forms, {\tt :compile-toplevel} specifies that the
compiler must evaluate the body at compile time in the evaluation
{\word environment\/}, and {\tt :load-toplevel} specifies that the
compiler must arrange to evaluate the body at load time For
non-toplevel {\function eval-when} forms, {\tt :execute} specifies
that the body must be executed in the run time {\word environment\/}.
The behavior of this construct can be more precisely understood in
terms of a model of how {\function compile-file\/} processes forms in
a file to be compiled. There are two processing modes, called
``not-compile-time'' and ``compile-time-too''.
Successive forms are read from the file by the {\function
compile-file} in not-compile-time mode; in this mode, {\function
compile-file\/} arranges for forms to be evaluated only at load time
and not at compile time. When {\function compile-file} is in
compile-time-too mode, forms are evaluated both at compile time and
load time.
Processing of {\word top-level\/} forms in the file compiler is defined
as follows:
\beginlist
\itemitem{1.} If the form is a macro call, it is expanded and the
result is processed as a {\word top-level\/} form in the same
processing mode (compile-time-too or not-compile-time).
\itemitem{2.} If the form is a {\function progn\/} form, each of its
body {\word forms\/} is sequentially processed as a {\word
top-level\/} form in the same processing mode.
\itemitem{3.} If the form is a {\function locally\/}, {\function
macrolet\/}, or {\function symbol-macrolet\/}, {\function
compile-file\/} establishes the appropriate bindings and processes the
body forms as an implicit {\word top-level\/} {\function progn\/} with
those bindings in effect, in the same processing mode. (Note that
this implies that the lexical {\word environment\/} in which {\word
top-level\/} forms are processed is not necessarily the null lexical
{\word environment\/}.)
\itemitem{4.} If the form is an {\function eval-when\/} form, it is
handled according to Figure {\chapno--\the\capno}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\offinterlineskip
\halign to \hsize {\strut#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip
\dimen0 plus .5 fil&#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus 1fil
&#\hfil&#\hfil&#\hfil\cr
\noalign{\vskip -11pt}
\hfil{\bf A} & {\bf B} & {\bf C} & {\bf D}& {\bf Action}& {\bf Mode}\cr
\noalign{\hrule}
Yes&Yes&\hfil---&\hfil---&Process&compile-time-too\cr
No&Yes&Yes&Yes&Process&compile-time-too\cr
No&Yes&Yes&No&Process¬-compile-time\cr
No&Yes&No&\hfil---&Process¬-compile-time\cr
Yes&No&\hfil---&\hfil---&Evaluate&\omit\cr
No&No&Yes&Yes&Evaluate&\omit\cr
No&No&Yes&No&Discard&\omit\cr
No&No&No&\hfil---&Discard&\omit\cr
\noalign{\vskip -9pt}
}}
\caption{{\function eval-when\/} processing}
\endfig
Column {\bf A} indicates whether {\tt :compile-toplevel} is specified.
Column {\bf B} indicates whether {\tt :load-toplevel} is specified.
Column {\bf C} indicates whether {\tt :execute} is specified. Column
{\bf D} indicates whether the compiler is in compile-time-too mode.
The {\bf Action} column specifies one of three actions:
\beginlist
\item{}{\bf Process:} process the body as an implicit top-level
{\function progn\/} in the specified mode.
\item{}{\bf Evaluate:} evaluate the body as an implicit {\function
progn\/} in the dynamic execution context of the compiler, using the
evaluation {\word environment\/} as the global environment and the
lexical {\word environment\/} in which the {\function eval-when\/}
appears.
\item{}{\bf Discard:} The form is discarded.
\endlist
\itemitem{5.} Otherwise, the form is a {\word top-level\/} form that
is not one of the special cases. In compile-time-too mode, the
compiler first evaluates the form and then minimally compiles it. In
not-compile-time mode, the {\word form\/} is simply minimally
compiled. All subforms are treated as non-{\word top-level\/} forms.
Note that {\word top-level\/} forms are processed in the order in
which they textually appear in the file, and that each {\word
top-level\/} form read by the compiler is processed before the next is
read. However, the order of processing (including macro expansion) of
subforms that are not {\word top-level\/} forms and the order of
further compilation is unspecified as long as Common Lisp semantics
are preserved.
\endlist
{\function eval-when\/} forms cause compile time evaluation only at
{\word top-level\/}. Both {\tt :compile-toplevel\/} and {\tt
:load-toplevel\/} situation specifications are ignored for
non-toplevel forms. For non-toplevel forms, an {\function eval-when}
specifying the {\tt :execute} situation will be treated as if it were
a {\function progn} including the forms in the body of the {\function
eval-when}.
Figure {\chapno--\the\capno} lists macros that make definitions
available both in the compilation and run time {\word environments\/}.
It is not required that definitions made available to the compiler
this way be made available as if evaluated by the compiler in the
evaluation {\word environment\/}, nor is it required that be available
in subsequent compilation units or subsequent invocations of the
compiler. As with {\function eval-when\/}, these compile time side
effects happen only when the defining macros appear at {\word
top-level\/}.
% The specific details of the compile time side effects should go under
% the description of the macro in chapters 6 & 7.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\function defconstant}&{\function define-setf-method}&{\function defsetf}\cr
{\function defclass}&{\function defmacro}&{\function defstruct}\cr
{\function defgeneric}&{\function defmethod}&{\function deftype}\cr
{\function define-condition}&{\function defpackage}&{\function defvar}\cr
{\function define-method-combination}&{\function defparameter}&{\function in-package}\cr
{\function define-modify-macro}&{\function defproclaim}&\cr
\noalign{\vskip -9pt}
}}
\caption{Defining macros}
\endfig
\endsubSection%{File Compilation}
\beginsubSection{Compiler/Loader Interface}
% Reference: Issue QUOTE-SEMANTICS
The functions {\function eval\/} and {\function compile\/} are
required to insure that constants referenced within the resulting
interpreted or compiled code objects are {\function eql\/} to the
corresponding objects in the source code. {\function compile-file\/},
on the other hand, must produce an output file which, when loaded with
{\function load\/}, constructs the {\word objects\/} defined by the
source code and produces references to them.
In the case of {\function compile-file\/}, {\word objects\/}
constructed by {\function load\/} of the output file cannot be spoken
of as being {\function eql\/} to {\word objects\/} constructed at
compile time, because the compiled file may be loaded into a different
Lisp image than the one in which it was compiled. This section
defines the concept of {\word similarity as constants\/} which relates
{\word objects\/} in the the compile time {\word environment\/} to the
corresponding {\word objects\/} in the load time {\word
environment\/}.
The constraints on constants described in this subsection apply only
to {\function compile-file\/}; {\function eval\/} and {\function
compile\/} are not permitted to copy or coalesce constants.
\endsubSection%{Compiler/Loader Interface}
\beginsubSection{Constants}
An {\word object\/} can be used as a quoted constant processed by
{\function compile-file\/} if the resulting constant established by
loading the compiled file is {\word similar as a constant\/} to the
original.
The notion of similarity as a constant is not defined on all {\word
types\/}. Conforming implementations are required to handle such
{\word objects\/} by having the compiler and loader reconstruct an
equivalent copy of the {\word object\/} in some
implementation-specific manner, or by having the compiler signal an
error of type {\datatype error\/}. A conforming portable program must
not use {\word objects\/} of these {\word types\/} as constants in
code to be processed with {\function compile-file\/}.
The definition of {\word similar\/} is in terms of the relationship
of {\word dissimilarity\/}.
Two {\word objects\/} are dissimilar if and only if they are not
{\function eql} and one of the following holds: they are not of the
same {\word type\/}, they are of the same {\word type\/} but are not
of a {\word type\/} listed below, or they are of the same {\word
type\/} and satisfy the additional requirements listed for that type
as follows:
\beginlist
\item{} {\bf array:} they have different dimensions or they have the
same dimension and satisfy whichever of the following is appropriate:
\beginlist
\item{}{\bf one-dimensional array:} the values of one of the following
attributes are dissimilar: {\function length\/}, {\function
array-element-type\/}, and {\function elt\/} for all valid indices.
\item{}{\bf multi-dimensional array:} the values of one of the
following attributes are dissimilar: {\function array-element-type\/}
and {\function aref\/} for all valid indices.
\endlist
\item{}{\bf character:} they represent different characters
\item{}{\bf cons:} the values of their {\word car\/} components are
dissimilar or the values of their {\word cdr\/} components are
dissimilar
\item{}{\bf hash table:} either they have different tests or for all
one-to-one correspondences between the keys of the two tables, either
the corresponding keys are dissimilar or the corresponding values are
dissimilar.
\item{}{\bf number:} they represent different mathematical values
\item{}{\bf package:} their names are dissimilar as {\datatype
strings\/}
\item{}{\bf pathname:} they have a component whose values are
dissimilar
\item{}{\bf random state:} they produce different sequences of
numbers when {\function random} is repeatedly applied to them
\item{}{\bf string:} they are dissimilar as arrays
\item{}{\bf symbol:} one of them is interned and they are not
{\function eql}, or both are uninterned and their print names are
dissimilar as {\datatype strings\/}
\endlist
Note that two {\word objects\/} are dissimilar if there is a point of
dissimilarity between them.
Two objects are {\word similar\/} is and only if they are not {\word
dissimilar\/}.
If two constants appearing in the source code for a single file
processed with {\function compile-file\/} are {\function eql\/}, the
corresponding constants in the compiled code must also be {\function
eql\/}.
% Reference: issue CONSTANT-COLLAPSING
However, if two {\word objects\/} are {\function eql\/} in the
compiled code, the corresponding {\word objects\/} in the source code
might not have been {\function eql\/}. {\function compile-file\/} is
permitted to coalesce constants appearing in the source code if they
are similar as constants, except if the {\word objects\/} involved are
of type {\datatype symbol\/}, {\datatype package\/}, or {\datatype
structure\/}. {\word Objects\/} of these {\word types\/} are never
coalesced. In addition, the following are constraints on the handling
of constants during compilation using {\function compile-file}:
\beginlist
\item{}{\bf array:} If an {\datatype array\/} in the source code is a
{\datatype simple-array\/}, then the corresponding {\datatype array\/}
in the compiled code will also be a {\datatype simple-array\/}. If
the {\datatype array\/} in the source code is displaced, has a {\word
fill pointer\/}, or is adjustable, the corresponding {\datatype
array\/} in the compiled code might lack any or all of these
qualities. If an {\datatype array\/} in the source code has a fill
pointer, then the corresponding {\datatype array\/} in the compiled
code might be only the size implied by the fill pointer.
\item{}{\bf function:} Issue CONSTANT-FUNCTION-COMPILATION specifies
how the compiler and loader handle constant {\datatype functions\/}.
\item{}{\bf hash table:} Two {\datatype hash tables\/} are similar if
there is a one-to-one correspondence between the keys of the two
tables such that the corresponding keys and values are similar. If
there is more than one such one-to-one correspondence between the
keys of the two tables, the consequences are unspecified if the tables
are coalesced. Conforming code to be processed with {\function
compile-file\/} must not use a {\datatype hash table\/} as a constant
if it is not possible to construct a similar table with more than one
such one-to-one correspondence with the original.
\item{}{\bf packages:} The loader is required to find the
corresponding {\datatype package\/} object as if by calling {\function
find-package\/} with the package name as an argument. An error of
type {\datatype package-error\/} is signalled if no {\datatype
package\/} of that name exists at load time.
\item{}{\bf random-state:} A constant {\datatype random-state\/}
object cannot be used as the state argument to the function {\function
random\/} because {\function random\/} modifies this data structure.
\item{}{\bf structure, standard-object:}
% Reference: issue LOAD-OBJECTS
{\word Objects\/} of type {\datatype structure\/} and {\datatype
standard-object\/} may appear in compiled constants if there is an
appropriate {\function make-load-form\/} method defined for that
{\word type\/}.
{\function compile-file\/} calls {\function make-load-form\/} on any
{\word object\/} that is referenced as a constant or as a
self-evaluating form, if the {\word object's metaclass\/} is
{\datatype standard-class\/}, {\datatype structure-class\/}, any
user-defined {\word metaclass\/} that is not a {\word subclass\/} of
{\datatype built-in-class\/}, or any of a possibly empty
implementation-defined list of other {\word metaclasses\/}.
{\function compile-file\/} will call {\function make-load-form\/} once
for any given {\word object\/} within a single file.
\item{}{\bf symbol:} Issue COMPILE-FILE-SYMBOL-HANDLING defines how
{\function compile-file\/} and the loader handle interned {\datatype
symbols\/}.
\endlist
\beginsubSection{Compile Time Error Handling}
% Reference: Issue COMPILER-DIAGNOSTICS
% The STYLE-WARNING condition needs to be integrated into the section
% describing the hierarchy of condition types.
{\function compile\/} or {\function compile-file\/} are permitted to
issue errors and warnings, including errors due to compile-time
processing of {\tt (eval-when (:compile-toplevel) ...) \/} forms,
macro expansion, and conditions signalled by the compiler itself.
Conditions of type {\datatype error\/} might be signalled by the
compiler in situations where the compilation cannot proceed without
intervention.
In addition to situations for which the standard specifies that
conditions of type {\datatype warning\/} must or might be signalled,
warnings might be signalled in situations where the compiler can
determine that the results have undefined consequences or that a run
time error will be signalled. Examples of this situation are as
follows: violating type declarations, altering or assigning the value
of a constant defined with {\function defconstant\/}, calling built-in
Lisp functions with a wrong number of arguments or malformed keyword
argument lists, referencing a variable declared {\tt ignore\/}, and
using unrecognized declaration specifiers.
The compiler is permitted to issue warnings about matters of
programming style as conditions of type {\datatype style-warning\/}.
Examples of this situation are as follows: redefining a function using
a different argument list, calling a function with a wrong number of
arguments, not declaring {\tt ignore\/} of a local variable that is
not referenced, and using declaration specifiers described in the
standard but ignored by the compiler.
Both {\function compile\/} and {\function compile-file\/} are allowed
to establish a default condition handler. If such a condition handler
is invoked, it must first resignal the {\datatype condition\/} to
allow user-established handlers to handle it. If all error handlers
decline, the default handler may handle the {\datatype condition\/} in
an implementation-specific way.
% Reference: issue WITH-COMPILATION-UNIT
Some warnings might be deferred until the end of compilation. See
{\function with-compilation-unit\/}.
\endsubSection%{Introduction}
\endSection
\endChapter
\bye
∂05-Jul-89 1625 Quinquevirate-mailer network address for Kathy Chapman
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Jul 89 16:25:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 620852; 5 Jul 89 19:02:29 EDT
Date: Wed, 5 Jul 89 19:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: network address for Kathy Chapman
To: Quinquevirate@sail.stanford.edu
Message-ID: <19890705230224.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
If you aren't Kathy Chapman, you can ignore this message.
If you are, could you send me a reply so I can find out your
address? Neither of the addresses I have for you work, because
neither of the hosts decwrl.dec.com nor aitg.enet.dec.com seems
to exist anymore. If one of those is in fact the right name,
the Received lines on your reply may give me a hint of the
problem (or may not).
∂18-Jul-89 0858 Quinquevirate-mailer ISO reviewers
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Jul 89 08:57:56 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA08286; Tue, 18 Jul 89 08:57:32 PDT
Message-Id: <8907181557.AA08286@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA08286; Tue, 18 Jul 89 08:57:32 PDT
From: chapman@aitg.enet.dec.com
Date: 18 Jul 89 11:55
To: quinquevirate@sail.stanford.edu
Subject: ISO reviewers
Following are the names of the people who volunteered when I "called
for participation". I don't know two of the people, and don't know
the specialities of the ones who didn't say.
Please let me know if this is a reasonable list of reviewers for the
ISO submission only. I will send the sources out electronically
and will hope to get reviews by early next week.
__________________________________________
Name Area of expertise
__________________________________________
Patrick Dussud ?
Sandra Compilation, anything except CLOS, mathematical
functions, and FORMAT
John Burger (mitre) ?
Cris Perdue Compilation, packages, loop, glossary
David Gray CLOS, compilation, pathnames, packages
Bil (Sun) ?
__________________________________
Section/function Reviewer
__________________________________
5.1 KMP
5.2-5.4 Moon?
3.1-3.4 Kim Barrett?
Glossary KMP, Cris
6.1 RPG
ADJUST-ARRAY Patrick
MAKE-ARRAY
COMPILE RPG, Sandra
COMPILE-FILE
DEFSTRUCT
DEFMACRO
EVAL-WHEN
DEFINE-COMPILER-MACRO
MACROEXPAND
DEFPACKAGE
DELETE-PACKAGE
DEFUN
DECLARE Patrick
PROCLAIM
TYPE-OF
FLET David Gray
LET-LETSTAR
LABELS
MULTIPLE-VALUE-BIND
MULTIPLE-VALUE-CALL
OPEN Bil
READ
WRITE
PROG Patrick, John Burger
RETURN
SETF
UNWIND-PROTECT
IF
QUOTE
PROGN
PROGV
BLOCK
TAGBODY
CATCH
THROW
RETURN-FROM
GO
VALUES
VALUES-LIST
FUNCALL
APPLY
ASSERT KMP
DEFINE-CONDITION
HANDLER-CASE
DEFCLASS David Gray
DEFINE-METHOD-COMBINATION
DEFMETHOD
SYMBOL-MACROLET
∂23-Jul-89 1429 Quinquevirate-mailer Progress
Received: from lucid.com ([192.26.25.1]) by SAIL.Stanford.EDU with TCP; 23 Jul 89 14:29:28 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA07545g; Sun, 23 Jul 89 14:26:37 PDT
Received: by challenger id AA16856g; Sun, 23 Jul 89 14:27:58 PDT
Date: Sun, 23 Jul 89 14:27:58 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8907232127.AA16856@challenger>
To: quinquevirate@sail.stanford.edu
Subject: Progress
Well, I've basically finished 4.2 and am part way through 4.1. The early
parts of 4.1 needed a lot of work, and I expect the remainder to be easier.
The big problem is that while working on 4.1, I had to change stuff in
4.2 and 7.2 (glossary). 4.1 is all I'll be able to do before mailing it
to ISO. Foo.
-rpg-
∂26-Jul-89 1428 Quinquevirate-mailer "signalling" vs "signaling"
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89 14:28:47 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632122; 26 Jul 89 17:30:00 EDT
Date: Wed, 26 Jul 89 17:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: "signalling" vs "signaling"
To: RPG@Lucid.COM
cc: chapman%aitg.dec@DECWRL.DEC.COM, JLZ@Lucid.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
quinquevirate@sail.stanford.edu
Message-ID: <19890726212946.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
I'm told you have unilaterally decided to change the spelling of
"signalled" to "signaled" and the spelling of "signalling" to "signaling".
I want you to be aware that the very idea that you might do this
upsets me personally a great deal.
The spelling of these words was discussed at length by the condition
handling committee. It was the group's consensus to use that spelling.
The dictionary by my desk at this moment ("Merriam-Webster; Webster's
Ninth New Collegiate Dictionary") says that either spelling is equally
correct. At the time of the discussion in the error handling committee,
several people cited other references to American dictionaries which
gave the two spellings equal status.
The spelling issue came up again a while back on CL-Editorial and it
was determined that the current spelling is fine.
Given that several respected authorities (dictionaries) agree that this
issue is a matter of individual preference, and not a matter of
right vs wrong, the issue comes down to the more subjective issues of
"status quo" and "personal respect".
Status quo gets involved because the error system which is the father
of this error system, the Symbolics error system, spells these words
with a double-L. I believe that this early precedent should have some
weight.
Personal respect becomes involved because as an individual I have invested
a large amount of time in the error system, and I feel that in the case
of a border-line call like this, I should have earned some say. The fact
that you're the last person to have his hands on this document before it
goes out to ISO does not impress me--might does not always make right in
these situations.
I think that it must be true that if the roles were reversed and I made
a similar play to change something in the presentation of CLOS without
your approval, you would react as I am now reacting. Indeed, nearly
every change to any CLOS-related wording that I have suggested to Kathy
has been accompanied by a phrase like "run this by RPG and/or Moon
first, just to be sure"--not always because I am unsure of my technical
opinion, but sometimes just because I don't think it's my place to be
making such decisions behind your back. If this were an issue of clear
right-vs-wrong, I would yield to the clearly right answer. And I think
you would, too. But if it was a case where there was a credible source
backing up a particular decision, I think you would want some say in how
CLOS was presented as part of your due for having put in your time on
creating it. Please afford me similar respect in this situation.
Please use the double-L spellings, and don't make us waste further time
at this critical juncture when all our times are better spent on more
important aspects of the document.
∂26-Jul-89 1550 Quinquevirate-mailer re: "signalling" vs "signaling"
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89 15:50:34 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632218; 26 Jul 89 18:51:31 EDT
Return-path: <RPG@SAIL.STANFORD.EDU>
Received: from SAIL.STANFORD.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 632181; 26 Jul 89 18:12:53 EDT
Message-ID: <bCxi1@SAIL.Stanford.EDU>
Date: 26 Jul 89 1440 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: re: "signalling" vs "signaling"
To: KMP@STONY-BROOK.SCRC.SYMBOLICS.COM
Resent-To: chapman%aitg.dec@DECWRL.DEC.COM, JLZ@Lucid.COM, quinquevirate@sail.stanford.edu
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Wed, 26 Jul 89 18:51 EDT
Resent-Message-ID: <19890726225125.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
[In reply to message sent Wed, 26 Jul 89 17:29 EDT.]
Well, every dictionary I have lists it first, the OED says one L is the
American spelling, the Chicago Manual of Style says to use one L (through
indirection by using its prescription to the use the first spelling of any
word with several listed spellings in any dictionary in a list of
dictionaries, all of which list one L first), every writer I talk to says
to use one L, every article I have read in the last 3 years spells it with
one L, and GNUEmacs wants me to spell it with one L.
This has nothing to do with personal respect - I'm simply trying to
follow contemporary American usage as best as I can discover it.
Note that I also include most punctuation (but not all) within
right double quotes ``sort of like this,'' which is both illogical
and contrary to British usage but is American usage.
I used to spell ``signalled'' with two L's until I was confronted with
the very facts I'm listing here.
-rpg-
∂26-Jul-89 1557 Quinquevirate-mailer re: "signalling" vs "signaling"
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89 15:57:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632225; 26 Jul 89 18:58:40 EDT
Date: Wed, 26 Jul 89 18:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: re: "signalling" vs "signaling"
To: RPG@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, chapman%aitg.dec@DECWRL.DEC.COM,
JLZ@Lucid.COM, quinquevirate@sail.stanford.edu
In-Reply-To: <bCxi1@SAIL.Stanford.EDU>
Message-ID: <19890726225832.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 26 Jul 89 1440 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Well, every dictionary I have lists it first,
Did you check the key up front to see if order matters? See below.
the OED says one L is the American spelling,
Since when is the OED the recognized authority on American usage?
the Chicago Manual of Style says
I've worked with such `standard' style guides on newspapers and I have
to say that I think they have are far from "authoritative" on the issue
of what is generally permissible. They are clear on what "they" permit,
but that may be very different than what "English" permits. In most
cases, their real value is in their resolution of arbitrary issues which
would otherwise have perfectly balanced arguments on both sides, so that
people who have agreed up front to abide by them can just get along with
their work. Even most places I know of that have used these things have
private exception lists because they can't abide by all the rules, or
because some rules are so domain-specific as to be not useful or not
complete in other domains. Anyway, I certainly did not agree up front
to abide by any particular such guide, so I don't buy any attempts to
sneak such a thing in now after the fact--certainly not as an unbiased
authority on correctness, which these things do not typically profess to
be.
every writer I talk to says to use one L,
Aha! I always suspected you didn't listen to our writers. :-}
Seriously, though, I just wanted to underscore that the set of writers
you talk to isn't exactly a universal quantification of all writers
everywhere.
every article I have read in the last 3 years spells it with one L,
Funny. You reviewed an article by me on condition handling within the past
three L's. I question your memory.
and GNUEmacs wants me to spell it with one L.
Hardly authoritative. Again, it's more important for a SPELL program to
permit either spelling just so it can catch cases where you use one spelling
in one place and another in another place than it is for a program to allow
all possible spellings. They really ought to write a SPELL program that
knew "foo" and "fu" were both legit and that noticed you used "fu" once
and then complained when you used "foo" later (or vice versa). If they did
have such featureful SPELL programs, and if GNU Emacs was such a one, then
you might well not get barfed at because it might well permit both spellings.
This has nothing to do with personal respect - I'm simply trying to
follow contemporary American usage as best as I can discover it.
Well, I'm a contemporary American. I spell it that way. My dictionary
says it's ok to do that. My dictionary says that people are pretty
evenly split on the issue. Why not follow my lead. Why is that not
exactly an issue of personal respect?
Note that I also include most punctuation (but not all) within
right double quotes ``sort of like this,'' which is both illogical
and contrary to British usage but is American usage.
No argument here.
I used to spell ``signalled'' with two L's until I was confronted with
the very facts I'm listing here.
Good, then look on this as an opportunity to go back to all those people
who tried to change you and tell them they were confused.
Quoting now, from my dictionary:
``VARIANTS
``When a main entry is followed by the word <or> and another
spelling, the two spellings are equal variants. Both are
standard, and either one may be used according to personal
inclination:
``mea.ger <or> mea.gre
``If two variants joined by <or> are out of alphabetical order,
they remain equal variants. The one printed first is, however,
slightly more common than the second.
``judg.ment <or> judge.ment
``When another spelling is joined to the main entry by the
word <also>, the spelling after <also> is a secondary variatn and occurs
less frequently than the first:
``quintet <also> quintette
``Secondary variants belong to standard usage and may be used according
to personal inclination. ...''
Note that it's clear here that the mere fact that "or" is used at all
means that it is proper -American- English no matter what the order.
However, the fact that in all three instances below they appear
alphabetically means that, according to the above rules, they are
also equally common in American usage. If they had not been, the
dictionary guys would have been forced to use <also> instead of <or>,
or to use <chiefly Brit> or some such.
``2signal <vb> signaled <or> signalled; signaling <or> signalling ...
signaler <or> signaller <n>.''
It's not like I'm picking a no-name obscure little dictionary that no
one has ever heard of. The fact is that a reputable American dictionary
backs me up. If you found another that didn't, I wouldn't believe
that that overruled me. At worst, I'd believe that it meant there was
dispute. And the only way for us to resolve this kind of dispute is to
just plain decide something on the basis of what suits our needs.
So I really do think it comes down to those non-technical criteria I
outlined before.
∂27-Jul-89 0745 Quinquevirate-mailer "signalling" vs "signaling"
Received: from Think.COM ([131.239.2.1]) by SAIL.Stanford.EDU with TCP; 27 Jul 89 07:45:33 PDT
Received: from fafnir.think.com by Think.COM; Thu, 27 Jul 89 10:46:26 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 27 Jul 89 10:44:11 EDT
Received: by verdi.think.com; Thu, 27 Jul 89 10:44:07 EDT
Date: Thu, 27 Jul 89 10:44:07 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8907271444.AA08980@verdi.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: RPG@lucid.com, chapman%aitg.dec@decwrl.dec.com, JLZ@lucid.com,
KMP@stony-brook.scrc.symbolics.com, quinquevirate@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 26 Jul 89 17:29 EDT <19890726212946.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: "signalling" vs "signaling"
I prefer two L's myself, but quite illogically so. There is a rule of
thumb here: when forming participles, the final consonant of the verb root
is doubled if and only if it is a lone consonant *and* an accent falls on
that syllable.
Here is an ex post facto explanation for this I have just now constructed.
The main reason for doubling a consonant in this way is to make it clear
that the preceding vowel is not to be lengthened, because when you form a
participle it is unclear whether a final vowel-lengthening silent "e" was
dropped when the participial ending was attached. However, if the final
syllable is unaccented then it is extremely unlikely to contain a long
vowel (it's hard to pronounce), and so consonant doubling would be
redundant and is therefore not done.
In this case, one can see that on paper (or CRT) "signaling" looks
as though it ought to be pronounced "signailing"; but just try to
say it out loud without shifting the accent to the second syllable.
English spelling stinks.
This is not to say that KMP's preference (mine also) should be overridden.
This is just background information.
--Guy
∂27-Jul-89 1138 Quinquevirate-mailer "signalling" vs "signaling"
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 27 Jul 89 11:38:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632677; 27 Jul 89 14:34:10 EDT
Date: Thu, 27 Jul 89 14:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: "signalling" vs "signaling"
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: chapman@aitg.enet.dec.com, JLZ@lucid.com, quinquevirate@sail.stanford.edu
In-Reply-To: <8907271444.AA08980@verdi.think.com>,
<19890726225832.0.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<bCxi1@SAIL.Stanford.EDU>,
<19890726212946.7.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<19890726201312.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890727183403.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think it is certainly within the charter of the drafting committee
to regularize spelling and word usage. I think it was discourteous
of Dick to do this to Kent's stuff without informing him, although
I expect Dick has the excuse that he didn't know that Kent cared
about this and assumed that the existing spelling had been chosen
arbitrarily and didn't really matter. I think it was excessive of
Kent to fly off the handle so vigorously over such a small point.
I thought the change from "signalled" to "signaled" might have been done
to make the Conditions section consistent with the existing Error
Terminology section. However, all versions of the Error Terminology
section that I have, the oldest and the newest, use the double L
spelling. On the other hand, 88-002R uses the single L. On the third
hand, the most recent version I've seen (in the one place I checked) of
the parts of the ANSI Common Lisp specification that evolved from
88-002R use the double L. Thus it appears that X3J13 has voted in
favor of both spellings at different times, but the trend is towards
the double L, for what that is worth (very little in my opinion, X3J13
has usually disclaimed responsibility for wording).
It would be better if our document used the same spellings throughout,
although if you consult the list of priorities that we all agreed to in
June, consistent spelling was not a priority. Since it's not a
priority, I'd rather not hear anything more about it. When the time
comes to make the spelling consistent, if I had to choose I would choose
the double L because that's what the Error Terminology section as voted
for by X3J13 uses, however either way would be equally acceptable as far
as I am concerned.
∂27-Jul-89 1204 Quinquevirate-mailer re: "signalling" vs "signaling"
To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
KMP@STONY-BROOK.SCRC.SYMBOLICS.COM
CC: chapman@AITG.ENET.DEC.COM, quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Thu, 27 Jul 89 14:34 EDT.]
Well, grumble. I'm not going to try to guess to whom I might be acting
discourteously for every word I change in this document. All I noticed is
that Kathy routinely changed all instances of ``signaling'' to
``signalling'' whenever I produced a section that said `signaling.' I
simply informed her I was trying to follow what I believe is both the
current and increasingly adopted usage and asking her not to undo it.
I don't think voting for a proposal is voting for either its wording or,
more absurdly, its spelling. 88-002R was voted in before conditions or
error terminology, so its spelling conventions have priority?????
-rpg-
∂27-Jul-89 1242 Quinquevirate-mailer Characters
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Jul 89 12:41:59 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA00345g; Thu, 27 Jul 89 12:39:12 PDT
Received: by challenger id AA01072g; Thu, 27 Jul 89 11:53:49 PDT
Date: Thu, 27 Jul 89 11:53:49 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8907271853.AA01072@challenger>
To: quinquevirate@sail.stanford.edu
Subject: Characters
I thought the notion of ``repetoire'' was replaced by ``script.''
I just saw this in the draft:
``{\datatype Standard-chars\/} are a subrepertoire of {\datatype
base-characters}.''
Should I replace it with
``{\datatype Standard-chars\/} are a {\word sub-script\/} of {\datatype
base-characters}.''
since ``subscript'' is wrong too?
-rpg-
∂27-Jul-89 1402 Quinquevirate-mailer Characters
Received: from arisia.xerox.com by SAIL.Stanford.EDU with TCP; 27 Jul 89 14:02:26 PDT
Received: from masunter.parc.Xerox.COM by arisia.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA23586; Thu, 27 Jul 89 14:02:13 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA00411; Thu, 27 Jul 89 14:02:45 PDT
Message-Id: <8907272102.AA00411@masunter.parc.xerox.com>
Date: Thu, 27 Jul 89 14:02:45 PDT
From: <masinter@arisia.xerox.com>
To: rpg@lucid.com
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Thu, 27 Jul 89 11:53:49 PDT <8907271853.AA01072@challenger>
Subject: Characters
I'm not clear what part of the text of the character proposal was
actually passed. Clearly "subscript" or "sub-script" is misleading
terminology.
The reason why character terminology is difficult is because the words
refer to things that people use in their every day life and outside of
LISP. I think the words "repertoire" and "script" are used to explain
the 'real world' foundations of actual use of characters in written
language and actual use of characters in ISO standards for the
interchange of information containing written language.
Here's my opinion:
When we want to talk about Common Lisp constructs, we can use Common
Lisp terminology, and leave the "repertoire" and "script" to our
explaination of how the Common Lisp terminology maps to the real world.
Thus, you should replace it with "STANDARD-CHAR is a subtype of
BASE-CHARACTER." As in,
"STANDARD-CHAR" is a type, that corresponds to a script.
STANDARD-CHAR is a subtype of BASE-CHARACTER. BASE-CHARACTER also
corresponds to a script, and the characters that correspond to
STANDARD-CHAR are a subset of those that correspond to BASE-CHARACTER.
∂27-Jul-89 1454 Quinquevirate-mailer Characters
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 27 Jul 89 14:54:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632887; 27 Jul 89 17:56:07 EDT
Date: Thu, 27 Jul 89 17:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Characters
To: Richard P. Gabriel <rpg@lucid.com>, masinter@arisia.xerox.com
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8907271853.AA01072@challenger>,
<8907272102.AA00411@masunter.parc.xerox.com>
Message-ID: <19890727215608.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 27 Jul 89 11:53:49 PDT
From: Richard P. Gabriel <rpg@lucid.com>
I thought the notion of ``repetoire'' was replaced by ``script.''
I have fairly good records on this character stuff. It was "registry"
that was replaced by "script" (in March). "Registry" was then reintroduced
with a different meaning.
"Repertoire" is just a synonym for "any [mathematical] set of characters."
I just saw this in the draft:
``{\datatype Standard-chars\/} are a subrepertoire of {\datatype
base-characters}.''
Should I replace it with
``{\datatype Standard-chars\/} are a {\word sub-script\/} of {\datatype
base-characters}.''
since ``subscript'' is wrong too?
Subtype is the right word here. Note that in June we eliminated the
distinction between named repertoires and types, since types are also
named sets of objects. A named character repertoire is just a subtype
of CHARACTER.
Be extremely extra sure while editing in this area not to introduce any
new "registry" versus "repertoire" typos.
Date: Thu, 27 Jul 89 14:02:45 PDT
From: <masinter@arisia.xerox.com>
I'm not clear what part of the text of the character proposal was
actually passed.
I have fairly good records on this character stuff, but only on paper,
and my handwriting isn't good enough to optically scan them in. Linden
promised to update the character committee document immediately after
the meeting, but I have not seen any sign that he has done so. Should
we harass him? Or find somebody else to do it? I really think the
final version of that document is valuable for archival purposes, and
should be an X3J13 document. Even the stuff that did not get included
in the language this time around is valuable as a possible framework
for the future and should not just be lost.
The reason why character terminology is difficult is because the words
refer to things that people use in their every day life and outside of
LISP. I think the words "repertoire" and "script" are used to explain
the 'real world' foundations of actual use of characters in written
language and actual use of characters in ISO standards for the
interchange of information containing written language.
Here's my opinion:
When we want to talk about Common Lisp constructs, we can use Common
Lisp terminology, and leave the "repertoire" and "script" to our
explaination of how the Common Lisp terminology maps to the real world.
"Repertoire", "coded character set", and "character script" -are- Common
Lisp terminology, now that character issue 2.0.1 has passed. Of course
this doesn't mean we have to use those terms to the exclusion of existing
Common Lisp terms. In particular I can think of no case where the
word "repertoire" needs to be used in the Common Lisp specification.
Thus, you should replace it with "STANDARD-CHAR is a subtype of
BASE-CHARACTER." As in,
Agreed.
"STANDARD-CHAR" is a type, that corresponds to a script.
STANDARD-CHAR is -not- a script. See the definition of script in
the character committee report.
STANDARD-CHAR is a subtype of BASE-CHARACTER. BASE-CHARACTER also
corresponds to a script,
BASE-CHARACTER is certainly not a script, since its definition is
completely implementation-dependent except that it is a supertype of
STANDARD-CHAR.
and the characters that correspond to
STANDARD-CHAR are a subset of those that correspond to BASE-CHARACTER.
True.
∂27-Jul-89 1508 Quinquevirate-mailer Characters
Received: from arisia.xerox.com by SAIL.Stanford.EDU with TCP; 27 Jul 89 15:08:45 PDT
Received: from masunter.parc.Xerox.COM by arisia.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA01235; Thu, 27 Jul 89 15:08:12 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA00427; Thu, 27 Jul 89 15:07:42 PDT
Message-Id: <8907272207.AA00427@masunter.parc.xerox.com>
Date: Thu, 27 Jul 89 15:07:42 PDT
From: <masinter@arisia.xerox.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: rpg@lucid.com, quinquevirate@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 27 Jul 89 17:56 EDT <19890727215608.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Characters
OK.
∂31-Jul-89 0023 Quinquevirate-mailer Status
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 Jul 89 00:23:13 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA11605g; Sun, 30 Jul 89 23:49:39 PDT
Site:
Received: by challenger id AA07191g; Sun, 30 Jul 89 23:50:56 PDT
Date: Sun, 30 Jul 89 23:50:56 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8907310650.AA07191@challenger>
To: quinquevirate@sail.stanford.edu
Subject: Status
I've got the draft ready to go - revised, retypeset, and photocopied.
I send it tomorrow. I thought you all might be interested in the
approach I've been taking to revising the draft, so I wrote down some
things.
*********************************************************************
The following are the principles I've been following in preparing the
draft:
1. Do not alter the technical content decided by X3J13.
2. Describe the language in terms of its linguistic features and not
in terms of implementation. For example, do not say that evaluation of
subforms in generalized reference must be left to right, but list the
operators for generalized reference that are defined and say that they
will do left to right evaluation of subforms. This prevents you from
having to make a big deal of the fact that user-defined SETF macros
might not do something the specification said must be done.
3. Describe additional semantic constraints imposed by the compiler in
terms of linguistic differences and not in terms of what the compiler
is allowed to do. The real constraint is on programs, not
implementations.
4. Do not anthropomorphize the language or its implementation. Avoid
saying that something is the case ``from Common Lisp's point of
view,'' or that signaling a condition is ``an admission by the program
that it cannot continue execution.'' This sort of expression is not
appropriate for a specification. Along these lines, do not introduce
phrasing that imputes processes, activities, or characteristics that
don't exist. For example, don't say:
``TYPE-OF can return an implementation-dependent type as long as
it is a type that SUBTYPEP can recognize.''
What is this process of recognition? Is there some point when the
language is doing this process? Is this a term that needs to be
defined? Say this instead:
``TYPE-OF can return an implementation-dependent type that is suitable
as an argument to SUBTYPEP.''
This, or something like it, says what you really mean.
5. Avoid saying that the implementation will, must, or can do things
if it can prove some statement. It is better to say that if the
statement is true, the linguistic effect will be or might be something
specific. Probably no implementation will have a theorem prover, and
the failure of the implementation to display the linguistic effect is
due to the failure of the implementor to determine effective test code
to test for the condition, not to the failure to prove. Consider the
classic factorial function, F. Would you describe it as: F produces
factorial of its argument if it can prove that the argument is a
non-negative integer.
6. Do not use Common Lisp function names as verbs. Say this:
``The file produced by {\function compile-file} can be loaded into
Lisp.''
Or say this:
``The file produced by {\function compile-file} can be loaded by using
{\function load} into Lisp.''
Don't say this:
``The file produced by {\function compile-file} can be {\function
load}ed into Lisp.''
If a new word is being defined using a Common Lisp function name, define
it as a term. Say this:
``The {\datatype symbol\/} {\tt foo} is interned in the {\tt slang}
{\datatype package}.''
Don't say this:
``The {\datatype symbol\/} {\tt foo} is {\function intern}ed in the
{\tt slang} {\datatype package}.''
Plain English is the language we assume the reader understands. We are
describing Common Lisp using this language plus a little computer
science and mathematics. In a formal semantics we could use part of
Common Lisp to define the rest, but even so we would not invent words
like SETQ as an English verb.
7. Try not to start a sentence with a Common Lisp function name. Try
to qualify each Common Lisp name with its type, as in:
``The function {\function load} can be used to load a file produced by
{\function compile-file}.''
This provides a lot of local information without a lot of words.
8. Don't give advice to users. This might seem like a heartless thing
to say, but the specification is a statement of what the language
does. What users should do depends on the implementation, the software
organization within which the user operates, the culture, and other
factors. Stating advice is a guess that that advice will be true under
all conditions. If you stick to the facts about the effect of
language constructs, you cannot misguess.
9. Don't make claims that might be false. Do not say that compiled
code is faster than interpreted code. Don't say that compiled code
probably will be faster than interpreted code. Don't say some sort of
error will probably be signaled. Don't state that something will
typically be done. State what will happen or be true in all
implementations (those things that will be true because the
specification states they will be). In fact, don't make any claims at
all beyond the semantics of Common Lisp.
10. Don't provide implementation advice. You might be tempted to want
to talk about great new techniques or something not obvious. But
someday this advice will be passe. Providing implementation details
might confuse someone into believing that the semantics follows
what the implementation advice states.
11. Don't say that some operation uses some Common Lisp function
unless that is what is required by the language. For example, don't
say compile-file uses READ to read expressions unless you mean that a
Lisp that is otherwise in conformance with Common Lisp fails to
conform because compile-file does not use READ. Don't assume readers
will know you don't mean literally a phrase or statement. That is,
don't assume that if you say that compile-file uses READ, the reader
will know you mean that in some implementations it might not as long
as the same effect is obtained.
12. Try to build in as few assumptions as possible about current
implementation technology. Whenever you say something about a
requirement, make sure the statement is true at least of classic
implementations, compiler-only ones, and interpreter-only ones. Don't
assume the existence of stack frames, garbage collectors, tags, linear
memory, computer addresses, operating systems, native code, byte code,
traversing interpreters, linkers, or any concept or term currently
related to computers that is not needed by the specification.
Use Lisp objects as the lowest level memory model.
13. Don't overspecify. Don't say too much in the belief that
overspecification is the means to precision. Being precise is not the
same as specifying all behavior. Being precise is saying exactly what
is required and not one word more. Think as carefully about what you
don't say as about what you do say. When you specify something, think
about whether everything you have said is required for conformance. If
not, think of those things that are required and find a way to say
only those things. This is the hardest principle.
14. Don't use an algorithmic specification. If you specify something
by algorithm you are specifying that that very algorithm is required
unless you take pains to say it isn't. Think of what part of the
algorithm is required or what facts about the process or the effects
are required. For example, if you are describing an operation that
sorts, talk about the result satisfying a set of constraints, not some
sorting algorithm. Sometimes you can think of no other way to describe
something than an algorithm. In that case, explain that it is the
effect and not the algorithm that matters.
15. Don't define a new term unless you really need it. Sometimes you'd
be surprised at how short a descriptive phrase you can come up with.
16. Use standard American usage, punctuation, and spelling. Pick a
dictionary or two, a set of usage guides, and stick to them. I use the
Random House Dictionary of the English Language (Second Edition,
Unabridged) and Webster's Second International Dictionary
(Unabridged), and Follett's Modern American Usage and Fowler's Modern
English Usage. I use the first spelling of all variant spellings (this
is supported by the Chicago Manual of Style). I use minimal
punctuation, trying to write sentences that are unambiguous and
understandable when all punctuation is stripped. Put commas and
periods inside closing double quotes except double quotes in Common
Lisp strings.
I know much American usage is not logical.
I use ``between'' instead of ``among'' when I want to emphasize that
the relationships described hold between pairs of objects rather than
among the objects as a group (Gowers Complete Plain Words supports
this).
Don't say this:
``x and/or y''
Say this:
``x, y, or both''
17. Typesetting: "foo" is a Lisp string and ``foo'' is foo in quotes.
Don't use single quotes (`foo'). The following is the proper typesetting
of hyphens etc:
a. implementation-dependent (hyphen)
b. the range 0--9, Chapters 1--5 (en dash)
c. this fails---it is stupid (em dash)
Italics correction (typeset \/) is used only with italics or slanted
fonts, except just before a period or comma:
This is a {\word word\/} in the middle of a sentence.
This is sentence ends with a {\word word}.
This sentence has in the middle a {\word word}, which is cute.
This is sentence seems to end with a {\word word\/}; but it really
doesn't.
The following are neither italics nor slant: \function, \bf, \tt.
18. Don't say ``allow'' when you mean ``provides a mechanism.'' The
operator SETF allows you to supply a generalized reference rather than
only a variable because it provides a mechanism to update any location
specified by a generalized reference. The function APPLY allows you to
supply a symbol in place of a function.
19. Don't use idioms, especially American ones - this is an
international document. Don't use jargon, especially US computer
jargon. People besides US Lisp hackers will read this specification.
As much of it as possible should be understandable to ordinary
intelligent people. This specification is not a netmail message.
20. Don't write an essay on the various factors or ramifications of
some point. For example, don't explain that depending on RANDOM to
launch missiles might not have a harmless side effect even though it
depends on things whose individual effects are harmless. This is
interesting, but it is irrelevant. People are smart enough to know
that words like ``harmless'' are being used in a narrow field of
discourse and can apply it wisely.
Don't explain all the ways a user interface to a restart might be
written, because that's something the implementor will worry about,
not the reader of the specification.
Depend on the intelligence of the readers to determine the boundaries
of your meaning and don't worry overly that they might not. It's fun
to argue the corner cases, but it's not fun to read those arguments.
21. If you find yourself reading dictionaries to dredge up
justification for a word, a phrasing, or an interpretation, rewrite.
If you find that the word you've chosen relies on a secondary or
uncommon definition, it's the wrong word. If when you strip all
puncutation, the sentence is confusing or ambiguous, rewrite it unti
the punctuation doesn't matter. Your descriptions should not need once
ounce of justification. If one person fails to understand it, you
wrote the wrong thing.
22. Read your descriptions with an eye towards literal interpretation.
If there is a humorous intrepretation, rewrite. Here is an example
from an article about C++:
``If I am writing a program in assembly language, I must constantly
worry about the state of the machine.''
Does he mean that when he is so hacking, the machine might be falling
apart? Or that the machine is suffering distress at being programmed
in such a primitive manner? What he means is that there is a set of
bits and conditions that represent the state of the computation that
is maintained by the computer, and correct assembly programs must
maintain, alter, inspect that state. This is an additional concern
the assembly language programmer must face. And does he really mean he
torments himself over it, or does he simply need to pay careful
attention to it?
The point is, if there is unintentional humor in what you say, the
reader will be distracted and lose what you're trying to say. And the
reader will question your carefulness.
∂31-Jul-89 1954 Quinquevirate-mailer re: Dick's guidelines
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 31 Jul 89 19:54:44 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA03069; Mon, 31 Jul 89 18:29:11 PDT
Message-Id: <8908010129.AA03069@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA03069; Mon, 31 Jul 89 18:29:11 PDT
From: chapman@aitg.enet.dec.com
Date: 31 Jul 89 03:41
To: quinquevirate@sail.stanford.edu
Subject: re: Dick's guidelines
I'm sorry to say that I'm not pleased at all with your message.
Your comments, although they sound well-founded to a person who
hasn't done much thinking about most of them, are the result of a
few weeks' worth of thought about what should go into this book
and how the information should be imparted. Your general guidelines
about specification writing were correct, but obvious to anyone
who has ever written a spec, so why did you bother to write them?
The only thing I can conclude from your message is that you would
like to take over writing the standard, because you can't possibly
think that I will have the time or inclination to proliferate your
style throughout the rest of the document (which turns out to be
most of the document). There is too much else to do.
I like to be objective, take criticism in the light in which it
was intended, and move on. In this case, I have to analyze the
source of the criticism and object to the validity of the
recommendations. I will be contacting the other members of the
drafting committee to get their points of view and will act
according to group consensus. Meanwhile, I doubt I will be sending
out anything to X3J13 as promised.
>6. Do not use Common Lisp function names as verbs. Say this:
>
>``The file produced by {\function compile-file} can be loaded into
>Lisp.''
>
>Or say this:
>
>``The file produced by {\function compile-file} can be loaded by using
>{\function load} into Lisp.''
>
>Don't say this:
>
>``The file produced by {\function compile-file} can be {\function
>load}ed into Lisp.''
This is a method of imparting information. "load" is not a word
that means the same everywhere. Used as an English word, it doesn't
have the semantics associated with the "load" we describe in this
standard.
>Plain English is the language we assume the reader understands. We are
>describing Common Lisp using this language plus a little computer
>science and mathematics. In a formal semantics we could use part of
>Common Lisp to define the rest, but even so we would not invent words
>like SETQ as an English verb.
This advice would be fine if Lisp itself didn't redefine so much
plain English. Using Lisp terms in plain English is plain confusing.
>7. Try not to start a sentence with a Common Lisp function name. Try
>to qualify each Common Lisp name with its type, as in:
>
>``The function {\function load} can be used to load a file produced by
>{\function compile-file}.''
>
>This provides a lot of local information without a lot of words.
This is style. It imparts little information and there's a big
chance that the wrong words will be attached to a function name
by accident (e.g. The special form "load") that would be much
more confusing than just not saying anything.
>8. Don't give advice to users. This might seem like a heartless thing
>to say, but the specification is a statement of what the language
>does. What users should do depends on the implementation, the software
>organization within which the user operates, the culture, and other
>factors. Stating advice is a guess that that advice will be true under
>all conditions. If you stick to the facts about the effect of
>language constructs, you cannot misguess.
I don't think this can be a hard and fast rule. The advice should
never be part of the "Description" section.
>9. Don't make claims that might be false. Do not say that compiled
>code is faster than interpreted code. Don't say that compiled code
>probably will be faster than interpreted code. Don't say some sort of
>error will probably be signaled. Don't state that something will
>typically be done. State what will happen or be true in all
>implementations (those things that will be true because the
>specification states they will be). In fact, don't make any claims at
>all beyond the semantics of Common Lisp.
In the error terminology, we have a "might signal an error".
>10. Don't provide implementation advice. You might be tempted to want
>to talk about great new techniques or something not obvious. But
>someday this advice will be passe. Providing implementation details
>might confuse someone into believing that the semantics follows
>what the implementation advice states.
Same as #9.
From #11 on down, it seemed as if you were lecturing me on the proper
way to do things in a specification. My first comment about that is
that I have been working on and thinking about this document totally
for 2 years. If you had said these things 2 years ago, or even a
year ago, it would've made more sense to me. But now you suddenly
have the time/incentive to review this document and you feel you
can impose your style in ways that will cause the entire document
(most of which you haven't seen yet) to change. Which brings me
to my second comment: I don't have the time nor intention to make
most of the changes you suggest. It distresses me to even say that,
it infuriates me that I have been put in the position of having to
say it after all this time. You have attended most of the editorial
committee meetings, you have been given drafts starting in 3/88,
why have you waited so long to say anything? I expressed to you and
others many times that I first and foremost didn't want to be wasting
my time and the time of others by taking the wrong approach. If you
succeed in making the style of this book conform to your personal
needs, I will have wasted about a year's worth of time.
I am the first to agree that a lot more work needs to be done, but
I am MUCH MORE WORRIED about technical consistency and accuracy than
typesetting, for example, at this point.
At this point I don't know what to do. Your ISO document doesn't look
like the rest of the standard so something will have to change. As I
said, I have a long list of things to change, and the list doesn't
include your style preferences. I have been reassigned and will therefore
only be doing this job when there's available time. I feel now that
no change or decision I make is safe, and will therefore be very reluctant
to waste my time on the standard.
kathy
∂31-Jul-89 2151 Quinquevirate-mailer re: Dick's guidelines
To: chapman@AITG.ENET.DEC.COM, quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from chapman@aitg.enet.dec.com sent 31 Jul 89 03:41.]
Au contraire. You misunderstand all.
First, my qualifications:
1. I worked for nearly 2 years on the CLOS specification, which is part of
this document. During that time I thought long and hard about what a
specification is. I have spent virtually every working (almost = every
waking moment) working on this specification since June 1.
2. I publish 10-20 papers per year, and have been for more than 5 years. I
am frequently called upon to write committee reports. I have been
practicing and studying the craft, art, and profession of writing,
particularly, but limited to, technical writing, for 20 years. I think my
thoughts are a little more than the accumulated wisdom of two weeks.
Second, what was this message intended to be.
I changed a lot of material written by people other than those on this
committee. You will all see that material soon. I wanted you to know what
I was thinking when I made those changes. If we all agreed that these were
good guidelines, then there would be less flack later on.
Kathy, the only 2 things that you do that are contrary to my guidelines
are to accidentally mistypeset some things and to use Lisp names as words.
I changed the typesetting problems as I came across them using Emacs
macros I have, and I did not touch a single instance of the use of Lisp
names as words. I changed hardly one word in the function pages, except
to comment out those things you marked as ``to be deleted,'' and to fix
one or two technical errors. On typesetting, having learned what I know
about typesetting from Knuth, I tend to be picky about it. He teaches that
carelessness in typeseting in this day and age indicates carelessness in
thought. Being much more worried about technical correctness does not mean
that one ignores typesetting.
Using Lisp names as words is so pervasive that we cannot realistically
change that unless there is a mandate to spend the time. If you read the
CLOS material, you will see that we rarely used Lisp names as words, and
the original document never started a sentence with a Lisp name. I doubt
anyone was particularly confused by the discrepancy between Lisp names and
the English phrases we used.
If you didn't like that document, then you shouldn't have agreed to
let me work on this one.
If the message was to lecture anyone, it was to lecture the various people
whose prose we are including via the cleanups and other such material.
Those writeups are full of random debates and rambling, and I think we
have to tighten them up. I spent almost all my time rewriting 5.1
(because KMP's style, I hate to say it, is like a random walk. He has an
excellent textbook style and lecture style, but he is not in his element
here.) and chapter 4. Section 4.2 required several weeks because Sandra,
bless her heart otherwise, did not manage to make clear which environments
were used where, and what the relationships are between them. Moon helped
work that out, because I wasn't sure what the story was. Section 4.1 only
needed a little straightening of its presentation, which is left largely
as it was.
(If you think the ISO document is much different from the X3J13 document
you submitted to me, you must be horrendously mistaken about how
effectively I work. At several points I was working at the rate of 1
paragraph per hour.)
My message was simply a set of notes I made to myself as I worked on the
document to show you all what things I either tended to repair or that I
would like to see done.
Now, I really don't care whether anyone likes my writing style or
guidelines. It all boils down to a free market: If you honestly think
that chapter 4 and the section on conditions were better off before I
worked on them, feel free to revert back.
Why didn't I complain in March of 1988?
There was nothing to complain about then and there is nothing to
complain about now, except for the influx of odd material from the
cleanups, which is of variable quality.
Now, on to the point.
Not only do I not want to take over this document, but I was hoping to bow
out at this point. I tried to make the sections I worked on as close as I
could to what I think a specification should be, and now you (all) can do
one of three things: make the rest of the document like them, make them
like the rest of the document, make everything as different as you like.
-rpg-
∂01-Aug-89 1728 Quinquevirate-mailer Dick's guidelines
Received: from arisia.xerox.com by SAIL.Stanford.EDU with TCP; 1 Aug 89 17:28:21 PDT
Received: from masunter.parc.Xerox.COM by arisia.xerox.com with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA01804; Tue, 1 Aug 89 11:46:12 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA25400; Tue, 1 Aug 89 11:11:02 PDT
Message-Id: <8908011811.AA25400@masunter.parc.xerox.com>
Date: Tue, 1 Aug 89 11:11:02 PDT
From: <masinter@arisia.xerox.com>
To: chapman@aitg.enet.dec.com
Cc: quinquevirate@sail.stanford.edu
In-Reply-To: chapman@aitg.enet.dec.com's message of 31 Jul 89 03:41 <8908010129.AA03069@decwrl.dec.com>
Subject: Dick's guidelines
I read Dick's message as some guidelines on how to rewrite stuff that
got added recently -- cleanup issues, the condition system, the new
glossary, etc. I didn't read it as a criticism of you. It seemed like
these were principles that you mainly had followed. There only seem to
be a couple of important areas where you seem to differ (there doesn't
seem much leverage in arguing whether we use 'plain english', is
there?) I think the issue is that if anybody else writes something
for you, we should agree on style guidelines. Right? Dick produced
some, and you have some disagreements about it. I think most of his
advice is of the form of "things to take out to improve technical
consistency and accuracy." If we're worried about technical
consistency and accuracy, we can help out a bit by removing
implementation advice that may be incorrect, at odds with changes in
the semantics; we can remove 'advice to users' that might be incorrect
or incompatible. We can improve technical accuracy by disambiguating
whether we mean "some process which resembles LOAD" from "the actual
call to the function LOAD". I think Dick is trying to help achieve the
goals you want to accomplish "technical consistency and accuracy".
Maybe he needs to be more suave about it. Think of Dick's list as
"things for reviewers to keep in mind." Does it give too much
implementation advice that might be outdated? Lets take it out. Do we
describe in great detail how a user might use a construct, with style
guides? Maybe we should take it out, especially if it would shorten
the standard some.
Right?
Larry
- - - - - - - - - - - -
6> "Do not use Common Lisp function names as verbs...."
I think that using Lisp functions as verbs is a little bit too cute
and it is probably a good idea to avoid it, but it isn't a big deal.
7> Try not to start a sentence with a Common Lisp function name...
I like reading "The function LOAD can be used ..." better than reading
"LOAD can be used ..." where there's even the slightest possibility
that someone might think "The property LOAD can be used..." or "The
variable LOAD can be used ...." or "The EVAL-WHEN tag LOAD can be used
..."
8> "Don't give advice to users..."
>> I don't think this can be a hard and fast rule...
I don't think any of these rules are "hard and fast", are they?
Seems like good advice, though. Is there any particular instance where
you and Dick disagree about 'advice to users'?
9> "Don't make claims that might be false..."
This seems like good general advice, and there are a couple of
exceptions, like "might be signalled". Its a good thing to keep in
mind when reviewing the standard, though.
10> "Don't provide implementation advice...."
Your response was "Same as #9", but I'm not sure how it applies.
Clearly there are some cases where we've been unable to describe
things except in terms of a reference implementation, and other places
where we've been unable to describe how someone might use something
('what's this for, anyway?') without some description about possible
implementations. Again, a good thing to keep in mind when reviewing.
∂01-Aug-89 2223 Quinquevirate-mailer
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Aug 89 22:23:29 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA15134; Tue, 1 Aug 89 22:24:01 PDT
Message-Id: <8908020524.AA15134@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA15134; Tue, 1 Aug 89 22:24:01 PDT
From: chapman@aitg.enet.dec.com
Date: 2 Aug 89 01:21
To: quinquevirate@sail.stanford.edu
Subject:
>Now, I really don't care whether anyone likes my writing style or
>guidelines. It all boils down to a free market: If you honestly think
>that chapter 4 and the section on conditions were better off before I
>worked on them, feel free to revert back.
Forgive me, but this is a silly comment. You must have been tired when
you made it. Of course anything that has been worked on and carefully
considered by a person of your background will be better than what was there.
That's not the issue!
>Why didn't I complain in March of 1988?
>
>There was nothing to complain about then and there is nothing to
>complain about now, except for the influx of odd material from the
>cleanups, which is of variable quality.
Although I should be more specific at this point, I'm sure you'll agree
that a large number of your guidelines were very general and applied
to the document before the clean-ups were ever incorporated.
>Now, on to the point.
>
>Not only do I not want to take over this document, but I was hoping to bow
>out at this point. I tried to make the sections I worked on as close as I
>could to what I think a specification should be, and now you (all) can do
>one of three things: make the rest of the document like them, make them
>like the rest of the document, make everything as different as you like.
This is really awful, you know. I think the gist of what I said was
misinterpreted by you. Except for maybe one or two things, I am not
wedded to any particular style or guideline. So I'm not arguing in
favor of what the document looked like before you made corrections.
My real objection is that if you went through the part of the document
that was submitted to ISO and made it look and sound a lot different
from the way the rest of the document looks, someone will have to
resolve the differences. A year ago I would have had NO PROBLEM with
that, six months ago I would have had little problem with that. Now
I don't have time to do a proper job of it and that's the problem.
Your dropping out after creating the ambiguity, even though the
reasons might have been good and concrete and well-meaning, is
pretty awful.
kathy
∂04-Aug-89 1137 Quinquevirate-mailer Tempest in a Teapot
To: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I spent the last few days at a workshop stewing over the guideline
problem. I think there is more sound and fury than substance. I would
describe the ISO submission as follows:
The conceptual part (chapters 1-5, chapter 8. Section 6.1) is a little
cleaned up.
The function pages (the rest of chapter 6) is slightly better typeset
(mostly accomplished by 2 emacs macros I have). I think I might have
changed 5 paragraphs in the entire function pages part. I suspect no one
outside this group but Sandra and Pitman would notice any difference
between Kathy's last draft and this one.
The major things I did in the function pages, which actually didn't make
it into the ISO submission, was to delete an implementation suggestion,
and I made the descriptions of FUNCALL and APPLY consistent.
I think the best idea is to take a look at what I did and judge how
different it is.
-rpg-
∂12-Aug-89 1516 Quinquevirate-mailer issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Aug 89 15:16:16 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.2-cs)
id AA13563; Sat, 12 Aug 89 16:16:59 -0600
Received: by defun.utah.edu (5.61/utah-2.2-leaf)
id AA06599; Sat, 12 Aug 89 16:16:54 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8908122216.AA06599@defun.utah.edu>
Date: Sat, 12 Aug 89 16:16:53 MDT
Subject: issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
To: quinquevirate@sail.stanford.edu
Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE says:
Additional arguments that do not correspond to slot names but
are merely present to supply values used in subsequent initialization
computations are allowed.
Can the variables in the BOA constructor lambda list that *do*
correspond to slot names be referenced in subsequent initialization
forms as well? If CLtL says anything about this, I can't find it.
I assume that this does not change the requirement on CLtL p. 309 that
the default-init forms specified in the slot descriptors (as opposed
to initialization forms appearing in the BOA constructor lambda list)
are evaluated in the lexical environment of the DEFSTRUCT form?
-Sandra
-------
∂14-Aug-89 1857 Quinquevirate-mailer I think we agreed to send the part of the standard that we sent to ISO
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Aug 89 18:57:14 PDT
Received: from AITG.ENET by decwrl.dec.com (5.54.5/4.7.34)
id AA02735; Mon, 14 Aug 89 18:57:30 PDT
Date: Mon, 14 Aug 89 18:57:27 PDT
Message-Id: <8908150157.AA02735@decwrl.dec.com>
Received: from AITG.ENET by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA02735; Mon, 14 Aug 89 18:57:30 PDT
From: chapman@aitg.enet.dec.com (14-Aug-1989 1646)
To: "quinquevirate@sail.stanford.edu"@decwrl.dec.com
Cc: review material for X3J13@decwrl.dec.com
Subject: I think we agreed to send the part of the standard that we sent to ISO
to X3J13 for the review. We need to get the review material in the mail
in the next week so that the committee will have time for a thorough
review, and so that we'll have time to consider the comments we are
bound to get.
I can get the package together and mail it, but the ISO submission
had the following problems that should be corrected:
1. Glossary term usage was irregular.
2. Section 3.1 was omitted.
3. The intros to a couple of the chapters were messed up.
4. There were disclaimers in section 2.2 that need to be corrected.
5. Fonting in the syntax section isn't consistent.
I also received several comments at the last minute that there wasn't
time to include.
Finally, we need to determine whether the "tracer" flags to indicate
what came from which X3J13 issue should be included in the review
material. I think its presence will encourage more careful review.
Please let me know what you think ASAP so I can get this review
material in the mail.
kathy
∂14-Aug-89 2055 Quinquevirate-mailer re: I think we agreed to send the part of the standard that we sent to ISO
To: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from chapman@aitg.enet.dec.com sent Mon, 14 Aug 89 18:57:27 PDT.]
I thought we promised to send to X3J13 exactly what was sent to ISO. I
think we ought to simply copy the draft as sent to ISO. It will take me a
day or so to get the tape made to sent to Kathy, and then she will have to
rerun TEX over the mess. I made some changes to the macros, and so if she
also did, she might need to integrate my changes to them.
I think there is nothing wrong with the disclaimers in section 2.2. What
needs to be checked and possibly corrected is the material that the
disclaimers warn might be inaccurate. I was unable to take the time to
verify that the international character set material and the type
hierarchies were correct. If there is anything we can take a bath on in
the draft, it's international characters.
The tracer material has been flushed from the ISO draft by redefining the
macros that delimit them (to be no-ops). Some material that was listed as
candidates for deletion have been commented out (but is still in place).
-rpg-
∂15-Aug-89 0834 Quinquevirate-mailer review material for X3J13
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 15 Aug 89 08:33:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 641959; 15 Aug 89 11:35:55 EDT
Date: Tue, 15 Aug 89 11:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: review material for X3J13
To: quinquevirate@sail.stanford.edu
In-Reply-To: <8908150157.AA02735@decwrl.dec.com>
Message-ID: <19890815153631.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 14 Aug 89 18:57:27 PDT
From: chapman@aitg.enet.dec.com (14-Aug-1989 1646)
I think we agreed to send the part of the standard that we sent to ISO
to X3J13 for the review. We need to get the review material in the mail
in the next week so that the committee will have time for a thorough
review, and so that we'll have time to consider the comments we are
bound to get.
Agreed.
I can get the package together and mail it, but the ISO submission
had the following problems that should be corrected:
1. Glossary term usage was irregular.
2. Section 3.1 was omitted.
3. The intros to a couple of the chapters were messed up.
4. There were disclaimers in section 2.2 that need to be corrected.
5. Fonting in the syntax section isn't consistent.
I can't comment on this, since I have not had the privilege of seeing
the ISO submission. I'll just say that I think that any corrections
that will take a lot of time are best skipped, in the interest of
getting the review started. Revised versions of some sections could
always be mailed later.
I also received several comments at the last minute that there wasn't
time to include.
Again if these will take a lot of time they should be skipped, otherwise
they should be put in.
Finally, we need to determine whether the "tracer" flags to indicate
what came from which X3J13 issue should be included in the review
material. I think its presence will encourage more careful review.
I think it's important to have all the tracer flags in the hardcopy for
this stage of review. I agree that omitting them from the ISO version
was a good idea, but not from the X3J13 version.
Please let me know what you think ASAP so I can get this review
material in the mail.
That's what I think.
∂15-Aug-89 0836 Quinquevirate-mailer review material for X3J13
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 15 Aug 89 08:36:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 641963; 15 Aug 89 11:38:00 EDT
Date: Tue, 15 Aug 89 11:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: review material for X3J13
To: quinquevirate@SAIL.Stanford.EDU
In-Reply-To: <bMBHc@SAIL.Stanford.EDU>
Message-ID: <19890815153836.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 14 Aug 89 2055 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I thought we promised to send to X3J13 exactly what was sent to ISO. I
think we ought to simply copy the draft as sent to ISO.
I don't know what was sent to ISO, but I was under the impression that ISO
was supposed to get only a subset of the document, whereas obviously we don't
want to conceal any portion of the document from the X3J13 reviewers.
I think there is nothing wrong with the disclaimers in section 2.2. What
needs to be checked and possibly corrected is the material that the
disclaimers warn might be inaccurate. I was unable to take the time to
verify that the international character set material and the type
hierarchies were correct. If there is anything we can take a bath on in
the draft, it's international characters.
I suggest that we allow the review process to address this. I'll be very
surprised if this is the only section that might be inaccurate.
∂15-Aug-89 1040 Quinquevirate-mailer re: review material for X3J13
To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Tue, 15 Aug 89 11:38 EDT.]
Moon:
I don't know what was sent to ISO, but I was under the impression that ISO
was supposed to get only a subset of the document, whereas obviously we don't
want to conceal any portion of the document from the X3J13 reviewers.
ISO got the parts that have been relatively polished. I believe the ISO
document was specifically requested by X3J13. I am perfectly happy to
ignore the request and do something else.
-rpg-
∂15-Aug-89 1053 Quinquevirate-mailer re: review material for X3J13
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 15 Aug 89 10:53:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 642042; 15 Aug 89 13:55:24 EDT
Date: Tue, 15 Aug 89 13:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: re: review material for X3J13
To: quinquevirate@SAIL.Stanford.EDU
In-Reply-To: <1NMYHT@SAIL.Stanford.EDU>
Message-ID: <19890815175555.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 15 Aug 89 1040 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Moon:
I don't know what was sent to ISO, but I was under the impression that ISO
was supposed to get only a subset of the document, whereas obviously we don't
want to conceal any portion of the document from the X3J13 reviewers.
ISO got the parts that have been relatively polished. I believe the ISO
document was specifically requested by X3J13. I am perfectly happy to
ignore the request and do something else.
Allow me to rephrase my remark. I think X3J13 review should commence for all
portions of the document, not only those that are polished, with the possible
exception of any portions that are currently undergoing substantial reworking
that will definitely be finished in time to allow X3J13 to review the results
by November. (I don't know whether there are any such portions.) For example,
I think the function pages should all be sent out for X3J13 review pretty soon,
or we'll fall way behind schedule.
∂18-Aug-89 2118 Quinquevirate-mailer What should be sent to X3J13 for review? The last I heard, Dick
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Aug 89 21:18:39 PDT
Received: from AITG.ENET by decwrl.dec.com (5.54.5/4.7.34)
id AA02637; Fri, 18 Aug 89 19:28:19 PDT
Date: Fri, 18 Aug 89 19:28:18 PDT
Message-Id: <8908190228.AA02637@decwrl.dec.com>
Received: from AITG.ENET by decwrl.dec.com (5.54.5/4.7.34)
for quinquevirate@sail.stanford.edu; id AA02637; Fri, 18 Aug 89 19:28:19 PDT
From: chapman@aitg.enet.dec.com (18-Aug-1989 0947)
To: "quinquevirate@sail.stanford.edu"@decwrl.dec.com
Cc: X3J13 review@decwrl.dec.com
Subject: What should be sent to X3J13 for review? The last I heard, Dick
wanted to send the ISO draft to them, but the ISO draft doesn't
have the tracers in it. Dick, are you going to rerun the ISO
draft to include the tracers? Are any other changes necessary?
We really need to resolve this quickly in order to make the November
meeting.
kathy
∂18-Aug-89 2146 Quinquevirate-mailer re: What should be sent to X3J13 for review? The last I heard, Dick
To: quinquevirate@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I am at IJCAI next week and on vacation until Sept 5. I sent Kathy a tape
with exactly the ISO text and macros. The last two macro definitions in
macros2.tex are the ones to comment out to get the tracers back in.
If you want to send exactly what I sent, Patrick Dussud can arrange to
make copies etc of that original (Patrick, it is on the top shelf of the
bookcase in my upstairs office, on the right-hand side of the shelf.)
Since everything was up in the air, I thought I'd wait until Kathy back
in the saddle to make the decision what to do.
-rpg-
∂22-Aug-89 0836 Quinquevirate-mailer issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 22 Aug 89 08:36:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 645328; 22 Aug 89 11:37:58 EDT
Date: Tue, 22 Aug 89 11:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: quinquevirate@sail.stanford.edu
In-Reply-To: <8908122216.AA06599@defun.utah.edu>
Message-ID: <19890822153755.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 12 Aug 89 16:16:53 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Apparently no one has responded to this?
Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE says:
Additional arguments that do not correspond to slot names but
are merely present to supply values used in subsequent initialization
computations are allowed.
Can the variables in the BOA constructor lambda list that *do*
correspond to slot names be referenced in subsequent initialization
forms as well? If CLtL says anything about this, I can't find it.
I would assume that the "BOA" constructor lambda list is the same as
any other lambda list in having sequential binding semantics, so that
those variables can be referenced. I don't claim to have any special
knowledge of or interest in defstruct constructors, though.
I assume that this does not change the requirement on CLtL p. 309 that
the default-init forms specified in the slot descriptors (as opposed
to initialization forms appearing in the BOA constructor lambda list)
are evaluated in the lexical environment of the DEFSTRUCT form?
I don't see how it could change it, since the writeup for that issue
doesn't say anything about lexical environments.
Editorial note upon re-reading the issue: the sentence
Keyword arguments default
in a manner similar to that of &OPTIONAL arguments: if no default
is supplied in the lambda-list then the slot initform is used;
otherwise the slot is not initialized -- its initial value is
undefined.
is partially bogus. The portion following the semicolon comes from a
misreading of CLtL, confusing the description of &AUX with the
description of &OPTIONAL, and should be replaced with
otherwise the default in the lambda-list is used.
X3J13 couldn't possibly have consciously voted for what this says, as it
is nonsense. I don't know where to look in the current draft
specification, which in any case I do not have a copy of, for the
corresponding text to see if this mistake got into our draft.
∂28-Aug-89 1605 Quinquevirate-mailer another DEFSTRUCT clarification
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Aug 89 16:04:53 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.2-cs)
id AA13251; Mon, 28 Aug 89 17:05:40 -0600
Received: by defun.utah.edu (5.61/utah-2.2-leaf)
id AA05328; Mon, 28 Aug 89 17:05:37 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8908282305.AA05328@defun.utah.edu>
Date: Mon, 28 Aug 89 17:05:35 MDT
Subject: another DEFSTRUCT clarification
To: quinquevirate@sail.stanford.edu
Does using the :CONSTRUCTOR option to DEFSTRUCT to define a BOA
constructor disable it from making the default keyword constructor? I
have always assumed that you had to explicitly say (:CONSTRUCTOR NIL)
if you did not want a keyword constructor, but it's been pointed out
to me by one of the other people here that CLtL doesn't actually say
that, and that the behavior of the various Lisps we have here differs
on this.
Also, can (:CONSTRUCTOR <name>) appear multiple times to get multiple
copies of the keyword constructor?
-Sandra
-------